[RFC] Removing -fpack-struct in C++ for 4.0

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Giovanni Bajo
> Sent: 07 October 2004 12:23
> To: Andrew Haley
> Cc: gcc
> Subject: Re: [RFC] Removing -fpack-struct in C++ for 4.0
> 
> Andrew Haley wrote:
> 
> > I'd be interested to see the rationale for including this option in
> > the first place.  Is there a link?
> 
> I tried googling for it but did not succeed. It was probably 
> meant only for C, and for freestanding environments.
> 
> Giovanni Bajo

  Yeh, it's used in embedded code, and it's handy for accessing data structs
that may be sent at arbitrary alignment in a stream of network or file data.
I know, it's poor technique to do this rather than properly serialising and
deserialising, but if your code is well modularised you can restrict the
performance hit by (frex) only compiling a single source file full of
accessor functions with the flag, and so I don't think it really ought to be
removed.  Hey, it would be just the thing for compiling all those xdr
functions in an autogenerated rpc stub file as well.

  People are still currently using as well, e.g.

http://groups.google.com/groups?hl=en&lr=&scoring=d&q=fpack-struct

  So I don't think it should be removed from C.  And if it's not going to be
removed from C, I don't really see why it should be forbidden to C++ users.
Let's not get into a discussion about how bad someone's engineering
practices would be if they wanted to use C++ in an embedded system and
-fpack-structs to allow unaligned accesses; it's not the compiler's job to
mandate good development methodology amongst the users.

  Now, I do of course agree that it's one of those dangerous flags, of the
give-them-enough-rope, that could trip up the incautious or inexperienced
user.  So I would instead suggest just strengthening and extending the
health warning attached to the flag in the documentation.  It already tells
people that their generated code will be very poor if they use it; it could
also point out that it breaks the C++ ABI and will generate masses of
spurious warnings from the standard system headers.  But anyone who actually
is using it with C++ in an embedded context probably isn't adhering to the
standard ABI and may equally well not have standard system lib headers:
people using C++ in an embedded environment often use it in a quite
stripped-down fashion, as a sort of enhanced-typesafety variant of C.  And
in that context, they might very well have a valid use for the flag.

  All IMO of course.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....