From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5664 invoked by alias); 7 Oct 2004 12:42:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5638 invoked from network); 7 Oct 2004 12:42:46 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 7 Oct 2004 12:42:46 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 13:42:25 +0100 From: "Dave Korn" To: "'Giovanni Bajo'" , "'Andrew Haley'" Cc: Subject: RE: [RFC] Removing -fpack-struct in C++ for 4.0 Date: Thu, 07 Oct 2004 13:16:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <12bb01c4ac60$07ef7cf0$dc4e2a97@bagio> Message-ID: X-OriginalArrivalTime: 07 Oct 2004 12:42:25.0251 (UTC) FILETIME=[18E75B30:01C4AC6B] X-SW-Source: 2004-10/txt/msg00288.txt.bz2 > -----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....