> >> If (as is looking likely) NetBSD/arm goes to -fshort-enums by default
> 
> >> nice if those enums that are generated by rpcgen were protected from
> >> causing ABI changes.  This patch arranges that by adding elements to
> >> each such enum so as to ensure that it's large enough to hold all the
> >> legal values of an XDR enum (32-bit signed integer).  Does this seem
> >> sensible?  Should asn1_compile do something similar?
> >
> >These would be needed for big-endian short-enum systems anyway!
> 
> <FX: Looks at the .c files generated by rpcgen> Eww.  rpcgen _really_
> shouldn't be assuming it can cast an enum foo * to an enum_t * without
> lossage.  I think that should be fixed in its own right.

I these are the XDR structures - rather than user interface ones - then
the types should probably be int32_t.  Or better something like 'struct
{...} xdr_int32' just to ensure they get passed through the endianness
convertion routines....  But maybe that is rather ott :-)
 
> >> +       f_print(fout, "\t__rpcgen_%s_min = -0x7fffffff-1,\n", name);
> >> +       f_print(fout, "\t__rpcgen_%s_max = 0x7fffffff,\n", name);
> >
> >So maybe they should be present for all ports!
> 
> Erm, they will be.  rpcgen's output will remain machine-independent.
> 
> >Maybe you should use the 'standard' constants, something like INT32_MAX
> >- but I can't find the reference to the C spec again!
> 
> Such constants do exist in <machine/int_limits.h>, and presumably
> somewhere more standard as well.  I'm reluctant to increase the
> number of headers that rpcgen'ed headers include, though, and it's#
> XDR's limits I'm interested in here, not the machine's.

Maybe - Personally I like some constants, you know where you stand when
the source contains 0x7fffffff.  Just that certain code styles
(typically favoured by the powers that be) think they should all be
hidden away!

> >If you want the generated code to be completely portable (to systems
> >that aren't 2's compliment) -0x7fffffff-1 is problematical!   Since -1
> >will do, maybe -0x7ffffff is -ve enough...

Has the advantage of avoiding any compiler issues with 0x80000000 that
might just still be lurking - guess they were fixed years ago though.

 
> My intention is to span the entire range that an XDR enum can assume.
> XDR enums are represented on the wire as 32-bit two's-complement
> integers.  If a C enum can't represent all those values on some
> systems then rpcgen is already broken on those systems.
> My patch just makes it rather more obvious.

FWIW the htonl routines could convert 1's compliment to 2's compliment. 
Mind you I suspect large amounts of everything fail miserably on such
systems anyway.

	David