This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: enum { BFD_ENDIAN_BIG, ...}
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Mon, 17 Dec 2001 10:30:01 -0500
- Subject: Re: enum { BFD_ENDIAN_BIG, ...}
- References: <3C1D4919.1000102@cygnus.com> <siheqq1jpg.fsf@daffy.airs.com>
> 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