Re: enum { BFD_ENDIAN_BIG, ...}

[Ian Lance Taylor <ian@airs.com>]

Andrew Cagney <ac131313@cygnus.com> writes:

> I'm curious.  Why/how did BFD_ENDIAN_BIG come to be first in the enum:
> 
> enum bfd_endian { BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNOWN };

I just wrote it that way.  Something had to be first.

> This has the (intended?) effect of memset(0) setting a value to
> BFD_ENDIAN_BIG where as code using the common host dependant
> BIG_ENDIAN / LITTLE_ENDIAN would have treated such a value as
> undefined.

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.

> 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.

Ian