[m-dev.] for review: direct retry

[Zoltan Somogyi]

On 16-Oct-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > Is this likely to be a problem in practice?
> 
> Yes.  For example, lcc doesn't support enum bitfields.

That's a convincing reason not to use them.

> You don't actually need to use casts.  GNU C doesn't warn about
> assigning char to enums that fit in char or vice versa.

Yes, I was bitten by this recently. I had a function whose first two args were
an enum and a bool, and the call which had them the wrong way around was not
picked up by gcc.

However, I would want to cast the field to the enum type before switching on
it, so I can get the benefit of gcc's warnings about the switch not covering
all the alternatives in the enum. Unfortunately, there is no way to enforce
the requirement for such casts if you declare the field an integer.

> (There are some C compilers that warn about conversions between
> integer types of different sizes, but in the case where one of
> the integer types is a enum type and the range of the enum fits
> within the size of the integer type, I don't think it is reasonable
> to issue a warning, and so if we do ever use a compiler which warns
> about such assignments, I think it would be reasonable to just turn
> such warnings off.)

I wouldn't like to turn off such warnings; I'd rather use casts in the places
where the assignment is known to be OK.

> For documentation purposes, rather than making the field be of type
> MR_int_least8_t, I would suggest using a typedef for MR_int_least8_t,
> with the typedef being declared at the same point where the enum is
> declared.  You could name the int_least8_t typedef `MR_EvalMethod' and
> leave the enum as just `enum MR_eval_method' or typedef'd to
> `MR_EvalMethodEnum'.

I'll go with the opposite convention, with MR_EvalMethod still being the enum
and a new type MR_EvalMethodInt which is typedef'd to MR_int_least8_t.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------