RE: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro

["Eric Raskin" <ehr at listworks dot com>]

IMHO, this just begs the question.  Grouping non-standard settings under a "native" switch may be a convenience, but it also makes for a difficult time in porting sofware.  It requires the user to know all of the individual non-standard settings that "native" implies.  I admit that they may need them all anyway, but isn't it better if they explicitly set the non-standard items for documentation purposes?  

Just imagine a makefile with "gcc -fnative" in it, so that the same build creates different behavior on different platforms.  Especially if those different behaviors are incompatible with each other, so that the build succeeds on one machine and fails on another.  

This bitfield issue is a perfect example.  If the code is written expecting signed bitfields (poor design, I know :-) ), but the native compiler expects unsigned bitfields, then -fnative would build incorrect code. If you didn't use -fnative, then the resulting output might be incompatible with other software already on the system.  Either way, you're in trouble.

So, I'm not sure that a "native" switch gets us anywhere....

     Eric Raskin

> -----Original Message-----
> From: Donn Terry [mailto:donn@interix.com]
> Sent: Thursday, June 03, 1999 11:20 AM
> To: law@cygnus.com
> Cc: Mark Mitchell; ehr; egcs-patches@egcs.cygnus.com
> Subject: Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro
> 
> 
> In a submitted patch, I have a fix for a vaguely similar problem
> (the way bitfields are packed in native vs. "gcc" mode.)
> 
> That same patch includes the mechanism for a flag (that could
> well set a number of finer-grained options) called "native-struct",
> which means "generate structures for the native compiler" (no,
> I didn't address the issue of 2 incompatible native compilers ;-) ).
> (There's also a corresponding __attribute__ to allow mixing the
> two.)
> 
> I'd suggest that rather than trying to address this issue one
> piece at a time (from a user point of view) that a single flag
> that is either "native" or "gcc" be provided.  (Under the covers,
> this probably sets a bunch of different flags on different
> architectures, but 99% of users don't care HOW a structure is
> layed out, just that it's compatible with existing code or the
> ABI, or with file images.)
> 
> No comment on what the default should be.
> 
> Donn
> 
> 
> Jeffrey A Law wrote:
> > 
> >   In message <19990602083208U.mitchell@codesourcery.com>you write:
> >   >
> >   > I don't think that this patch is in the spirit of GNU 
> CC, as recorded
> >   > in the current manual.  We could decide to change the 
> manual, but I
> >   > think it would be a not-insignificant change.  Before 
> doing so, I
> >   > suggest that the steering committee think carefully about the
> >   > rationale for doing so, and debate the manual section 
> quoted below.
> > This may not be in the spirit of GCC, but if we fail to 
> keep the signedness
> > of bitfields the same as it has already been on that 
> platform for years we
> > introduce a stupid and totally avoidable change in the ABI.
> > 
> > ie, that port has had signed bitfields for years.  Changing 
> it now is, IMHO
> > too late, this needed to have been caught and fixed a long time ago.
> > 
> > Note that it is still possible to explicitly ask for signed 
> or unsigned
> > bitfields.
> > 
> > And the signedness of bitfields does matter from an ABI 
> standpoint, contrary
> > to what the manual states.  I've been nailed badly by it in 
> the past.
> > 
> > jeff
> 
> -- 
> 
> ===================================================
> Donn Terry                  mailto:donn@interix.com
> Softway Systems, Inc.        http://www.interix.com
> 2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
> Tel: +1-970-204-9900           Fax: +1-970-204-9951
> ===================================================
>