enum { BFD_ENDIAN_BIG, ...}

enum { BFD_ENDIAN_BIG, ...}

[Andrew Cagney]

Hello,

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 };

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.

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.

	Andrew

Re: enum { BFD_ENDIAN_BIG, ...}

[Ian Lance Taylor]

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

Re: enum { BFD_ENDIAN_BIG, ...}

[Andrew Cagney]

> 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

Re: enum { BFD_ENDIAN_BIG, ...}

[Alan Modra]

While we're on this subject, note that initialising pointers (and FP) to
all-bits-zero via memset is not strictly portable.  Not all architectures
represent a NULL pointer as all-bits-zero.  The C-FAQ mentions a number
of such machines.  http://www.eskimo.com/~scs/C-faq/top.html

Alan

Re: enum { BFD_ENDIAN_BIG, ...}

[Richard Henderson]

On Tue, Dec 18, 2001 at 10:59:41AM +1030, Alan Modra wrote:
> While we're on this subject, note that initialising pointers (and FP) to
> all-bits-zero via memset is not strictly portable.  Not all architectures
> represent a NULL pointer as all-bits-zero.  The C-FAQ mentions a number
> of such machines.  http://www.eskimo.com/~scs/C-faq/top.html

Whatever.  None of them are live.

Nor, IMO, will there ever be another machine created with a non-zero
NULL.  The assumption is now so universally ingrained it would cause
more trouble than it would be worth.


r~

Re: enum { BFD_ENDIAN_BIG, ...}

[Alan Modra]

On Mon, Dec 17, 2001 at 04:45:21PM -0800, Richard Henderson wrote:
> On Tue, Dec 18, 2001 at 10:59:41AM +1030, Alan Modra wrote:
> > While we're on this subject, note that initialising pointers (and FP) to
> > all-bits-zero via memset is not strictly portable.  Not all architectures
> > represent a NULL pointer as all-bits-zero.  The C-FAQ mentions a number
> > of such machines.  http://www.eskimo.com/~scs/C-faq/top.html
> 
> Whatever.  None of them are live.

Heh.  I suppose I should have admitted noticing this strict portabilty
problem at various times, and couldn't be bothered fixing occurrences.
The thing is, a number of places in binutils do

memset (structp, 0, sizeof (*structp);

structp->ptr1 = NULL;
structp->ptr2 = NULL;
.
.

as if at some stage binutils authors were concerned about this
portability issue.  Typically, not _all_ pointers in the struct are
set to NULL, likely due to bitrot.  That's mildly confusing, and should
probably be fixed.  My inclination is to remove such "unnecessary"
initialisation.

Alan