Question about -ansi flag, and different size of struct from C and C++

[Ralf Corsepius]

On Mon, 2003-12-15 at 13:46, Leon Pollak wrote:
> On Monday 15 December 2003 14:36, Ralf Corsepius wrote:
> > On Mon, 2003-12-15 at 13:02, Oleg Ivanov wrote:
> > >     Hello list,
> > >     I have a problem. I defined struct like:
> > >         struct dummy {
> > >           int var1;
> > >           short var2;
> > >           int var3;
> > >        } __attribute__ ((packed));
> > >
> > >     and access to it from C and C++ code.
> > >     The problem is that size from C is 10 bytes and from C++ is 12
> > > bytes, I couldn't make that C++ packed that struct, exept removing -ansi
> > > flag from compiler string.
> > >     So I have two question, is there another method to ask C++ packed
> > > struct,
> >
> > __attribute__ is a gcc extension,
> > #pragma Packed rsp. __attribute__((packed)) are compiler-dependent
> > features,
> > "packing" in general is target dependent.
> I am too small to argue with Ralf therefore I ask: which target will interpret 
> the "packed" pragma different from "without holes, byte by byte"?
Many gcc-targets do. 

I regularily see the compiler warnings from the code in
c/src/libnetworking, where some code (IIRC, it's the goahead web-server)
uses #pragma packed ;). 

But I don't recall off-hand which targets don't support it.

>  I was sure 
> that this means the same everywhere...
No, it doesn't. In gcc, some targets support packing, some don't.

Other compilers (IIRC, Sun's Solaris C++ does) even re-sort structures
for optimization and/or packing (I might be wrong, but AFAIK, gcc-3.4
will also do this).

> > In one sentence: Don't do that! ;)
> And how to declare the HW dependent structures?
Well, in most cases, packing is not the actual problem, the actual
problem is structure IO. 

Almost anything (packing, volatile, alignment) about this is
non-portable.

One way to work-around this issue is to resort to byte/short/int IO and
to cast the values to a struct.
Another way is guard such structs in compiler-version guards
(__GCC_VERSION__ etc.) and to try getting away this way.

However, if portability is not a concern, and you know you'll stay with
gcc and a particular target, you can simply disregard this issue ;)

> > I don't know why gcc accepts __attribute__((packed)) and g++ doesn't.
> > IMO, gcc and g++ should both either refuse to take this code if using
> > -ansi or silently not pack.
> Here I can say - I use "packed" in C++ and it works, I don't know why this 
> does not work in your case. Look for some other causes.
Let me add: Nothing prevents you from not using -ansi in our code and to
use non-ansi-compliant functions there.

What I said on -ansi above, applies to the RTEMS source-tree. In
target-independent code there, we want to avoid using non-ansi-compliant
features and to stay as close to ansi/c89 as possible.

Apart from this, -ansi is a bit more than preventing using
non-ansi-compliant compiler features and functions, it also affects some
internal details in gcc.

Ralf