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