[IRCServices Coding] GCC3

[Finny Merrill]

On Tue, 26 Feb 2002, Trevor Talbot wrote:

> On Monday, February 25, 2002, at 09:48  PM, Andrew Church wrote:
> 
> >> Reordering is not permitted by the ANSI/ISO C standards.
> >
> >      That's what I thought, but a whole bunch of people seemed to think 
> > GCC
> > 3.0 was doing just that.
> 
> It occurs to me that this has been talked about as a somewhat-useful
> optimization.  The idea is to reorder struct members for optimal padding.
> But even if gcc did adopt this as an extension (I don't know if it does 
> or
> not), it would have to be disabled by default, as several things (such as
> ANSI offsetof()) would break.
> 
> >      Again, that's what I thought--compilers aren't supposed to pad more
> > than the largest type in the structure, and between structure members 
> > only
> > enough to align the next member to a multiple of its size.  I'm pretty 
> > sure
> > this is defined somewhere, and if not then it should be (see below).
> >
> >> Partly for this reason, mapping structs onto arbitrary data in
> >> memory results in undefined behavior.
> >
> >      It shouldn't, and if it did things would break all over the place.
> > Suppose you have two compilers, one of which is used to compile a 
> > program,
> > and the other of which is used to compile a library used by the program.
> > Now suppose the program passes a pointer to a structure (say, a FILE *) 
> > to
> > the library.  If the two compilers use different algorithms to pad
> > structure members, guess what happens?  Boom.
> 
> Actually, I was referring to things such as:
> 
>      struct tag {
>          char type;
>          uint_32 value;
>      } *s;
> 
>      char map[32];
should be unsigned char.
> 
>      /* load map with some data */
> 
>      s = (struct tag *)map;
> 
> But your point about compilers is a valid one; I don't know about
> POSIX (as someone else commented), but in general compilers adopt
> the same alignment scheme for a particular architecture.  After all,
> the architecture is what requires certain alignments anyway :)
> 
> -- Quension
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>