On Tue, Feb 19, 2002 at 02:33:55PM +0000, Christos Zoulas wrote:
> >
> > > I don't understand why we need fixed size enums in the api, since rpcgen
> > > will generate code that converts back and forth to ints...
> >
> >rpcgen'd enums might be passed around as arguments or used in structures
> >visible to the user of a shared library, at which point the size of the
> >resulting type is quite important.
> 
> Yes, but only if the parameter type of the function is 'enum blah'.
> If it is int/u_int, then there is no problem, because the default
> promotions handle it.
> 
> i.e.
> 
> foo(enum bar x)
> 
> can cause problems, but:
> 
> foo(int x)
> 
> will not.

Actually the ABI (probably) says that the above are actually equivalent!
The problems arise with 'foo( enum bar *x )'

> Maybe changing all functions that take enum args is easier.

For a variety of reasons - eg binary compatibility with shared
libraries, and programs that refuse to use the system header
files - that may not help.

My interpretation of the ARM ABI for enums (from this list)
is that they are required to behave like K&R integer types
(as opposed to ANSI C integer types).  In particular they
always promote to 'int' (or 'unsigned int') before any
arithmetic is done.

So:
    enum { a = 0x7fff, b = -0x7fff } e;
    int16_t s;
    e = a;
    s = a;
    printf( "%x %x\n", bar + (uint8_t)1, s + (uint8_t)1 );
should print "8000 ffff8000"

	David

-- 
David Laight: david@l8s.co.uk