This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BYTE_BITFIELD in symtab.h


> Hi!
> 
> Is the following thing in symtab.h realy useful?
> 
> 
> /* Don't do this; it means that if some .o's are compiled with GNU C
>    and some are not (easy to do accidentally the way we configure
>    things; also it is a pain to have to "make clean" every time you
>    want to switch compilers), then GDB dies a horrible death.  */
> /* GNU C supports enums that are bitfields.  Some compilers don't. */
> #if 0 && defined(__GNUC__) && !defined(BYTE_BITFIELD)
> #define BYTE_BITFIELD   :8;
> #else
> #define BYTE_BITFIELD           /*nothing */
> #endif
> 
> if BYTE_BITFIELD was defined to :8 the size of
>  "struct general_symbol_info" would decrease from 24 bytes to 20 bytes
> for a tipical 32 bit machine. 
> And gdb uses quite a few of those...
> 
> Isn't the price payed for being able to switch compilers too high in
> this case? 
> How common are compilers that don't support enum bitfields? 

Oh, what the heck I'll name names. ``gnu'' added this 1994-01-12 only to 
have ``kingdon'' disable it less than a month later (1994-02-07).  I 
agree with JimK.  I think that #if is nasty asking for trouble.

A quick glance at my (very old) tartan labs book suggests a compiler 
need only support unsigned bit fields.  If you think about it, that is 
probably the only thing with vaguely well defined and fairly portable 
semantics.

For the above my personal preference would be to zap that macro and then 
investigate some explicit pack/unpack or explicit (i.e. no macro) 
unsigned bitfields.

Fortuantly, that isn't my file :-)

enjoy,
Andrew

PS: JimB, did you know ``struct { unsigned :1; } foo'' is valid?




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]