svn commit: r210451 - head/sys/sys

[Kostik Belousov]

On Sun, Jul 25, 2010 at 09:55:10PM +0200, Nathan Whitehorn wrote:
> On 07/25/10 20:12, Kostik Belousov wrote:
> >On Mon, Jul 26, 2010 at 01:36:07AM +1000, Bruce Evans wrote:
> >   
> >>On Sat, 24 Jul 2010, Stefan Farfeleder wrote:
> >>
> >>     
> >>>declaring enums like this is not standard C code (seems to be a GCC
> >>>extension). I don't think we should use this feature in our headers.
> >>>       
> >>This is unfortunate.  This is because the size of an enum variable
> >>depends on its complete declaration.  This is an error unconditionaly
> >>with TenDRA.  It takes -pedantic to get a warning from gcc.
> >>     
> >I looked at the C99, and indeed, there is an explicit sentence
> >"A type specifier of the form enum identifier without an enumerator list
> >shall only appear after the type it specifies is complete."
> >
> >I fully agree with Bruce that this is unfortunate, or rather, makes
> >enum tag declaration completely unuseful. gcc extension greatly simplifies
> >dealing with the headers pollution.
> >
> >On the other hand, I disagree with the statement that the size of the
> >enum variable depends on the full declaration. It seems that C99
> >defines values of the enum to by of type int, and both i386 and
> >amd64 ABIs define enums as represented by 4-byte integers.
> >Yes, I am aware that C++ allows the enum to be assigned the
> >the shortest arithmetic type that can represent all enum values.
> >   
> 
> This is not actually true. Try adding a value that requires a 64-bit int 
> to your enum -- it will become 8 bytes. Also, the signedness of the type 
> depends on the values in the enumeration.

Well, the amd64 ABI has a note
"C++ and some implementations of C permit enums larger than an int. The
underlying type is bumped to an unsigned int, long int or unsigned long
int, in that order."

The gcc extension is consistent in this regard, since it only allows
to use pointers to enum without complete definition.

Did I already said that I miss it ? Sorry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20100725/559c87ba/attachment.pgp