On Tue, 2006-02-21 at 14:56 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> 
> > My feeling?  Absolutely, TYPE_MIN_VALUE and TYPE_MAX_VALUE should
> > represent the set of values that an object of the type may hold.
> > Any other definition effectively renders those values useless.
> 
> I agree -- with the obvious caveat that it need not be the case that the
> object actually have that value if the program has invoked undefined
> behavior.  So, if you have an 5-bit type, stored in a byte, and you
> manage to get 255 in that byte, and you read the value, you might see
> 255 at runtime -- but only because your program was busted anyhow.
Right.

This does highlight one of the issues that keeps nagging at me.
For an enumeration type, presumably we have TYPE_PRECISION set to
the minimum precision necessary to hold all the values in the enum.
What are TYPE_MIN_VAL/TYPE_MAX_VAL?    Does TYPE_MAX_VALUE include
values outside the enum, but which are included by the TYPE_PRECISION?

Consider

enum
{
  RED,
  GREEN,
  BLUE,
  BLACK,
  WHITE
}


for (color = RED; color <= WHITE; color++)

Now we might think that color is constrained to the values
RED .. WHITE.  However at runtime we can actually get
RED .. WHITE + 1.  Does TYPE_MAX_VALUE cover WHITE + 1?

If not, then we've got more latent bugs waiting to nail us.

It'll be simple enough to check, but if someone knows the
answer off the top of their head it would save me a few minutes
of investigative work.

jeff

Reply via email to