Subject: Re: rpcgen fix for -fshort-enums
To: <>
From: David Laight <david@l8s.co.uk>
List: tech-toolchain
Date: 02/06/2002 12:35:27
Todd Vierling wrote:

>  >  f_print(fout, "\t__rpcgen_%s_max = (enum_t)0x7fffffff, /* int32_t */\n", name);
>  f_print(fout, "\t__rpcgen_%s_min = (-__rpcgen_%s_max)-1,\n", name, name);

> 
> The cast to enum_t above is rather more for readability, not code
> correctness.  Just putting 0x7fffffff in there is a bit vague.  (Hence the
> comment, too.)
> 
> : If you are trying to define an enum with the same size as an arbitrary
> : typed integer then you have more fun (esp. if you want to avoid gcc
> : 'enhancements' to C).  Try ((uintmax_t)~(int_type)0) >> 1)...
> 
> It has to be *exactly* the size of an enum_t, no more and no less, as
> interpreted by rpc/types.h.  This is because rpcgen casts "enum foo *" to
> "enum_t *".

So if I decide that enum_t should be 64 bit should I expect the code to
continue to work....  adding the (enum_t) cast doesn't affect the size
of the generated enum so is totally superfluous.  The int32_t comment is
even worse!

The best comment (probably only needed in the rpcgen source, not the
generated code?) would be something like 'force enums to be 32 bit on
systems that have variable sized enums'.

	David