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

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

[Giovanni Bajo]

Hello,

following up to: http://gcc.gnu.org/ml/gcc/2004-02/msg01116.html, I'm going to
post a patch which removes -fpack-struct from the C++ frontend on mainline, and
a patch to add a deprecation warning to 3.4.3.

I do not think we need a full major version of deprecation time because the
option is totally incompatible with any library, eg., v3, as it totally breaks
the ABI and v3 itself is not built with this option. Thus, I doubt this option
is much used in C++ code. Moreover, the workaround for people doing
freestanding C++ is just to use pragma pack everywhere (at the top of a
project-wide header, for instance).

I would like to hear comments on this before I start working on the actual
patch.

Thanks,
Giovanni Bajo

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

[Andrew Haley]

Giovanni Bajo writes:
 > 
 > I would like to hear comments on this before I start working on the actual
 > patch.

I'd be interested to see the rationale for including this option in
the first place.  Is there a link?

Andrew.

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

[Giovanni Bajo]

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

RE: [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....

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

[Andrew Haley]

Dave Korn writes:
 > > -----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.

You don't need -fpack-stricts for that.  attribute((packed)) will do the job.

Giovanni suggested:

>> the workaround for people doing freestanding C++ is just to use
>> pragma pack everywhere (at the top of a project-wide header, for
>> instance).

Is that not reasonable?

Andrew.

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

[Giovanni Bajo]

Dave Korn wrote:

>   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.

The same can be done with either pragma pack or attribute((packed)). But this
way you can mark which structures you want to be laid out like that, and
structures used in system and external headers are not affected. -fpack-struct
does not provide any additional semantic to GCC that cannot be obtained
otherwise. It is just the wrong approach because it basically forces an ABI
change.

By putting pragma pack at the top of each file (or of a main global header) you
obtain the very same effect of -fpack-struct. And then, you can put it just a
few lines below the standard headers, and have only your structures packed.

>   People are still currently using as well, e.g.
>
> http://groups.google.com/groups?hl=en&lr=&scoring=d&q=fpack-struct

It's funny that the first link there (in French) is someone which asks
explanation about -fpack-struct: he doesn't understand how an user can mixmatch
code compiled with -fpack-struct with code compiled without it. So, I would
even argue that this option is caused confusion to our users. Later, another
link is to a message saying that it's better to avoid -fpack-struct and use
attribute((packed)) instead.

Giovanni Bajo

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

[Dave Korn]

> -----Original Message-----
> From: Giovanni Bajo 
> Sent: 07 October 2004 14:06

> Dave Korn wrote:
> 
> >   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.
> 
> The same can be done with either pragma pack or 
> attribute((packed)). But this way you can [...snip!]

  Yep, I know all that, which is why I said....

> 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.

  I'm not going to object very strongly.  If you really want rid of it, get
rid of it; it's not a flag that I ever use, so I have no personal interest
in the matter.  But I do think people will complain.

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

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

[Aaron W. LaFramboise]

Giovanni Bajo wrote:

> I do not think we need a full major version of deprecation time because the
> option is totally incompatible with any library, eg., v3, as it totally breaks
> the ABI and v3 itself is not built with this option. Thus, I doubt this option
> is much used in C++ code.

Could a deprecation period possibly hurt?  Is this option causing
problems of some sort such that it would be worthwhile to forego the
deprecation period?

If there is even one C++ project or developer that uses -fpack-struct,
it seems like it would be unfortunate to remove the feature without
deprecation.

I can't find any information on an official deprecation policy.  Perhaps
there should be one, maybe as part of the release procedure or release
criteria.  If a benign feature is to be removed without a deprecation
period on the grounds that it appears to be unused, it seems like this
should be in accord with some agreed on policy.

Aaron W. LaFramboise

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

[Joseph S. Myers]

On Thu, 7 Oct 2004, Aaron W. LaFramboise wrote:

> I can't find any information on an official deprecation policy.  Perhaps
> there should be one, maybe as part of the release procedure or release
> criteria.  If a benign feature is to be removed without a deprecation
> period on the grounds that it appears to be unused, it seems like this
> should be in accord with some agreed on policy.

Removal without deprecation period is generally because a feature turns 
out to have been broken for a long time so there can't be users of it 
because it doesn't work (or the users are going to stick to their very old 
stable compiler version anyway).  Past examples include typedef foo = bar 
and -fvolatile.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

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

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Joseph S. Myers
> Sent: 08 October 2004 01:06

> > I can't find any information on an official deprecation 
> policy.  Perhaps
> > there should be one, maybe as part of the release procedure 
> or release
> > criteria.  If a benign feature is to be removed without a 
> deprecation
> > period on the grounds that it appears to be unused, it 
> seems like this
> > should be in accord with some agreed on policy.
> 
> Removal without deprecation period is generally because a 
> feature turns 
> out to have been broken for a long time so there can't be users of it 
> because it doesn't work (or the users are going to stick to 
> their very old 
> stable compiler version anyway).  Past examples include 
> typedef foo = bar 
> and -fvolatile.

  Interestingly enough, -fvolatile did in fact have thousands of users,
although I guess nobody was really looking closely at what it actually did
to the code...!

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