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: enum { BFD_ENDIAN_BIG, ...}


> Andrew Cagney <ac131313@cygnus.com> writes:

> I didn't anticipate that the enum would be used in a field which was
> not initialized in a normal fashion.  I personally pretty much never
> privilege a particular element of an enum; either the enum matches an
> external definition, in which case all elements have explicit values,
> or the enum does not match an external definition, in which case none
> of the elements have explicit values.  I don't normally initialize
> structures using memset(0); I normally explicitly initialize all
> fields in one way or another.


I'm currently ``fixing'' gdb to explicitly initialize the relevant field.


>> GDB, which is trying to eliminate its dependance on those host
>> dependant macros is suffering minor heart burn as a result of the
>> difference - it has been assuming that ZERO indicated an uninitialized
>> (roughly BFD_ENDIAN_UNKNOWN) value.

> It should not break BFD to change the order of the enum values.  If it
> does, I would consider that to be a bug.  If you do change the order,
> I would (obviously) recommend an explicit = 0, and a comment
> indicating why BFD_ENDIAN_UNKNOWN has a zero value.


I'll think about it.  While something assuming zero might be a bug, I 
really don't want to break BFD.

thanks for the history,
Andrew


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