Re: [PATCH 5/6] convert object type handling from a string to a number

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 27, 2007, 16:24 UTC
Message-ID: <Pine.LNX.4.64.0702270816350.12485@woody.linux-foundation.org>
In-Reply-To: <alpine.LRH.0.82.0702270856360.29426@xanadu.home>

On Tue, 27 Feb 2007, Nicolas Pitre wrote:

Show 5 quoted lines

> > 
> > I am wondering if "enum object_type" and signed comparison here
> > are compatible.
> 
> Enums are signed as far as I know.

No they are not.

"enums" are traditionally "int", but it's not a requirement, and the technical C requirement is that they be "an integral size sufficiently large to hold all the possible values".

In other words, with a small set of values, it's entirely possible that the integral type in question be "unsigned char", for example.

It so happens that gcc will never *by*default* pick such a type for the particular set of values you have. By default (to match traditions) gcc will always pick "int" (or, thanks to a gcc extension, a bigger type if the values require it), but if you pass it "-fshort-enums" it will pick a smaller type.

And yes, it will actually pick "unsigned char", I think. Try it to be sure.

So to be portable, and to be safe, you really should make the error values part of the enum, ie you should add a

	OBJ_ERROR = -1,

if you want to make sure that the enum really can hold a negative number!

(In fact, on some embedded platforms, "-fshort-enums" is actually on by default - in order to keep data structures smaller)

		Linus