From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14293 invoked by alias); 17 Dec 2001 05:49:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11248 invoked from network); 17 Dec 2001 05:47:47 -0000 Received: from unknown (63.201.54.26) by sources.redhat.com with QMTP; 17 Dec 2001 05:47:47 -0000 Received: (qmail 18358 invoked by uid 10); 17 Dec 2001 05:47:46 -0000 Received: (qmail 25328 invoked by uid 269); 17 Dec 2001 05:47:39 -0000 Mail-Followup-To: binutils@sources.redhat.com, gdb@sources.redhat.com, ac131313@cygnus.com To: Andrew Cagney Cc: binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: enum { BFD_ENDIAN_BIG, ...} References: <3C1D4919.1000102@cygnus.com> From: Ian Lance Taylor Date: Sun, 16 Dec 2001 21:49:00 -0000 In-Reply-To: <3C1D4919.1000102@cygnus.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-12/txt/msg00149.txt.bz2 Andrew Cagney 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