gcc compile options affecting structure alignment?

I’ve found some differences in the layout of structures
depending on how a program was compiled. I’m not yet sure
what gcc/g++/qcc/QCC options affect what yet, and this doesn’t
seem to be documented. I’m using a C library from C++ code,
and the struct sizes and alignments for C-type structures
don’t match. (That took a while to figure out, but
I’ve verified it by printing “sizeof(structure)”, and
I’m seeing different values from C and C++ code.)

What compile options can cause changes in structure
alignment?

What’s the difference between “QCC -V gcc_ntox86_gpp” and
“QCC -V gcc_ntox86”?

Are there alignment differences between gcc/g++/qcc/QCC?

Does wrapping “extern “C” {” around a struct declaration
affect alignment?

What options are libraries supposed to be compiled with?

John Nagle
Animats

[Was: Re: gcc compile options affecting structure alignment?]

With the QNX 6.20 compilers and
libraries on x86, “bool” has a different alignment
in C and in C++. Try this program:

========= booltest.c =====
//
//
Size of bool test
//
#include <stdbool.h>
#include <stdio.h>
struct {
bool a;
bool b;
bool c;
bool d;
bool e;
} testbool;


int main()
{
printf(“Size of test structure is %d bytes.\n”,sizeof(testbool));
return(0);
}

Compiled with “qcc”, using no options, it prints
“Size of test structure is 5”.
Compiled with “QCC”, using no options, it prints
“Size of test structure is 20”.

This defect causes much grief in mixed C/C++ programs.
Structures used in both environments don’t match if
they contain “bool”. Programs then crash, overwrite
memory, and do other undesirable things.

This is actually a problem with gcc 2.x compilers.
In gcc 3.x compilers, sizeof(bool) = 1 in C++. See

http://gcc.gnu.org/ml/gcc/2002-04/msg01478.html

where the GCC developers have discussed this issue.

This problem has the effect of making Mindready’s IEEE-1394
support package unusable from C++, because of the use of
“bool” in C code.

Later versions of gcc supposedly produce the message “sizeof(bool)
inconsistent across compile modules” at link time, but
that doesn’t come out here.

John Nagle
Animats

John Nagle wrote:

I’ve found some differences in the layout of structures
depending on how a program was compiled. …

Aren’t there command line switches that affect the sizeof an enum?

Maybe, (wishful thinking) they affect the sizeof bool too.
If not, then there should simply be a command line switch to force it
one way of the other.

John Nagle wrote:

[Was: Re: gcc compile options affecting structure alignment?]

With the QNX 6.20 compilers and
libraries on x86, “bool” has a different alignment
in C and in C++. Try this program:

========= booltest.c =====
//
// Size of bool test
//
#include <stdbool.h
#include <stdio.h
struct {
bool a;
bool b;
bool c;
bool d;
bool e;
} testbool;


int main()
{ printf(“Size of test structure is %d bytes.\n”,sizeof(testbool));
return(0);
}

Compiled with “qcc”, using no options, it prints
“Size of test structure is 5”.
Compiled with “QCC”, using no options, it prints
“Size of test structure is 20”.

This defect causes much grief in mixed C/C++ programs.
Structures used in both environments don’t match if
they contain “bool”. Programs then crash, overwrite
memory, and do other undesirable things.

This is actually a problem with gcc 2.x compilers.
In gcc 3.x compilers, sizeof(bool) = 1 in C++. See

http://gcc.gnu.org/ml/gcc/2002-04/msg01478.html

where the GCC developers have discussed this issue.

This problem has the effect of making Mindready’s IEEE-1394
support package unusable from C++, because of the use of
“bool” in C code.

Later versions of gcc supposedly produce the message “sizeof(bool)
inconsistent across compile modules” at link time, but
that doesn’t come out here.

John Nagle
Animats

John Nagle wrote:

I’ve found some differences in the layout of structures
depending on how a program was compiled. …


Bill Caroselli
Q-TPS Consulting
(626) 824-7983

John Nagle <nagle@downside.com> wrote:

This defect causes much grief in mixed C/C++ programs.
Structures used in both environments don’t match if
they contain “bool”. Programs then crash, overwrite
memory, and do other undesirable things.

I’d generally strongly recommend against using bool in mixed C/C++
projects. You can use int or char instead, these are guaranteed to be
compatible.

Reason: bool is a builtin type in C++, whereas it isn’t in C (the
builtin type is called _Bool there, and pulling in stdbool.h just
aliases this type available as bool, IIRC). C++ is based on the old
ISO standard from circa 1990, and stdbool.h was only introduced 1999
into C. It is a pure coincidence (a compiler specific extension) that
you can use stdbool.h from C++.

-Gerhard

| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid’s vuasichdig, und lossds eich nix gfoin!
| – Dr. Kurt Ostbahn

Of course one can work around this defect. But that
does not make it less of a defect. Generally, the
C++ and C committees coordinate to make the two
languages compatible in the areas where they overlap.
Here, that wasn’t done. Thus, this is a defect.
Excuses are unacceptable.

John Nagle
Animats

Gerhard Wesp wrote:

John Nagle <> nagle@downside.com> > wrote:

This defect causes much grief in mixed C/C++ programs.
Structures used in both environments don’t match if
they contain “bool”. Programs then crash, overwrite
memory, and do other undesirable things.


I’d generally strongly recommend against using bool in mixed C/C++
projects. You can use int or char instead, these are guaranteed to be
compatible.

Reason: bool is a builtin type in C++, whereas it isn’t in C (the
builtin type is called _Bool there, and pulling in stdbool.h just
aliases this type available as bool, IIRC). C++ is based on the old
ISO standard from circa 1990, and stdbool.h was only introduced 1999
into C. It is a pure coincidence (a compiler specific extension) that
you can use stdbool.h from C++.

-Gerhard

I thought I was replying in the newsgroup for the
C++ standards committee, so that was a more standards-
oriented response. The answer for QNX is that the
GCC people recognized this mistake, which only
existed in the 2.7x through 2.9x compilers. The
next release of QNX will presumably move up to a 3.x
compiler and fix the problem.

When is that expected to happen?

John Nagle
Animats

John Nagle wrote:

Of course one can work around this defect. But that
does not make it less of a defect. Generally, the
C++ and C committees coordinate to make the two
languages compatible in the areas where they overlap.
Here, that wasn’t done. Thus, this is a defect.
Excuses are unacceptable.

John Nagle
Animats

Gerhard Wesp wrote:

John Nagle <> nagle@downside.com> > wrote:

This defect causes much grief in mixed C/C++ programs.
Structures used in both environments don’t match if
they contain “bool”. Programs then crash, overwrite
memory, and do other undesirable things.


I’d generally strongly recommend against using bool in mixed C/C++
projects. You can use int or char instead, these are guaranteed to be
compatible.

Reason: bool is a builtin type in C++, whereas it isn’t in C (the
builtin type is called _Bool there, and pulling in stdbool.h just
aliases this type available as bool, IIRC). C++ is based on the old
ISO standard from circa 1990, and stdbool.h was only introduced 1999
into C. It is a pure coincidence (a compiler specific extension) that
you can use stdbool.h from C++.

-Gerhard

John Nagle <nagle@downside.com> wrote:

next release of QNX will presumably move up to a 3.x
compiler and fix the problem.

It’s still a non-standard GCC extension.

When is that expected to happen?

I’d also be interested to know!

-Gerhard

| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp/
|
| Passts auf, seid’s vuasichdig, und lossds eich nix gfoin!
| – Dr. Kurt Ostbahn