455,515 Members | 1,772 Online
Need help? Post your question and get tips & solutions from a community of 455,515 IT Pros & Developers. It's quick & easy.

# Can you approximate subranges in C?

 P: n/a CBFalconer writes: It would be fairly easy to graft such a construct with: enum subrangetype {MINVAL .. MAXVAL}; where MINVAL and MAXVAL are constant integral values. Suppose you need an integer type "foo" that can represent MINVAL, MAXVAL, and all values in between. Will the following type do? typedef enum { foo_lo = MINVAL, foo_hi = MAXVAL } foo; Nov 13 '05 #1
9 Replies

 P: n/a In article <7w***************@sic.twinsun.com> Paul Eggert writes:Suppose you need an integer type "foo" that can represent MINVAL,MAXVAL, and all values in between. Will the following type do?typedef enum { foo_lo = MINVAL, foo_hi = MAXVAL } foo; This might be fixed in C99 (and no doubt someone will post about it if so), but in C89, at least, it is not guaranteed to work. A hypothetical "evil" implementation might make the enumerated type "foo" compatible with, e.g., unsigned char and thus give it a maximum integral range of [0..255], even if MINVAL is -32767 and MAXVAL is 32767. I doubt there are any compilers that do this, but I would be not terribly surprised to find 16-bit-"int" compilers that make enum foo compatible with plain (signed) int even when MINVAL is -2147483647 and MAXVAL is 2147483647, which is guaranteed to fit within plain mlong. -- In-Real-Life: Chris Torek, Wind River Systems (BSD engineering) Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: forget about it http://67.40.109.61/torek/index.html (for the moment) Reading email is like searching for food in the garbage, thanks to spammers. Nov 13 '05 #2

 P: n/a Chris Torek writes: In article <7w***************@sic.twinsun.com> Paul Eggert writes:Suppose you need an integer type "foo" that can represent MINVAL,MAXVAL, and all values in between. Will the following type do?typedef enum { foo_lo = MINVAL, foo_hi = MAXVAL } foo; This might be fixed in C99 (and no doubt someone will post about it if so) It has been fixed, in that the type chosen must be capable of representing all enumerated types; however, the constraint still exists that all of the constant expressions enumerated must be representable as an int, which means an implementation could find its work easiest by simply always using an int, and warning (at least) if an expression falls outside of that. In any case (to OP), C isn't Ada; you wouldn't have the advantage of being able to *constrain* the value to that range (if that's what you wanted). At any rate, you're at least as well off employing int as enum. HTH, -Micah Nov 13 '05 #3

 P: n/a "Chris Torek" wrote in message news:be**********@elf.eng.bsdi.com... In article <7w***************@sic.twinsun.com> Paul Eggert writes:Suppose you need an integer type "foo" that can represent MINVAL,MAXVAL, and all values in between. Will the following type do?typedef enum { foo_lo = MINVAL, foo_hi = MAXVAL } foo; This might be fixed in C99 (and no doubt someone will post about it if so), but in C89, at least, it is not guaranteed to work. Could you elaborate on what difference exactly you refer to here? As I recall, there is only wording improvement between those standards, C90+TCs and C99. -- Jun, Woong (my******@hanmail.net) Dept. of Physics, Univ. of Seoul Nov 13 '05 #4

 P: n/a "Micah Cowan" wrote in message news:m3************@localhost.localdomain... "Jun Woong" writes: "Chris Torek" wrote in message news:be**********@elf.eng.bsdi.com... In article <7w***************@sic.twinsun.com> Paul Eggert writes: >Suppose you need an integer type "foo" that can represent MINVAL, >MAXVAL, and all values in between. Will the following type do? > >typedef enum { foo_lo = MINVAL, foo_hi = MAXVAL } foo; This might be fixed in C99 (and no doubt someone will post about it if so), but in C89, at least, it is not guaranteed to work. Could you elaborate on what difference exactly you refer to here? As I recall, there is only wording improvement between those standards, C90+TCs and C99. From what I could read, C90 states only that enum be compatible with an integer type; which specific type is implementation-defined. There doesn't seem to be a requirement that it choose a type capable of representing all enumerated values (which would still be a poor QoI, of course, but still...). This was fixed in C99. From the TC2 for C90: In subclause 6.5.2.2, page 61, second paragraph of Semantics, change: Each enumerated type shall be compatible with an integer type; the choice of type is implementation-defined. to: Each enumerated type shall be compatible with an integer type. The choice of type is implementation-defined, but shall be capable of representing the values of all the members of the enumeration. -- Jun, Woong (my******@hanmail.net) Dept. of Physics, Univ. of Seoul Nov 13 '05 #5

 P: n/a Paul Eggert wrote: CBFalconer writes: It would be fairly easy to graft such a construct with: enum subrangetype {MINVAL .. MAXVAL}; where MINVAL and MAXVAL are constant integral values. Suppose you need an integer type "foo" that can represent MINVAL, MAXVAL, and all values in between. Will the following type do? typedef enum { foo_lo = MINVAL, foo_hi = MAXVAL } foo; I don't think this makes much sense without Pascal style BUILT IN RANGE CHECKING. Pascal has (optional) RANGE CHECKING for variables, which IIRC incvludes range check for SUBRANGES. Nov 13 '05 #6

 P: n/a "Paul Eggert" wrote in message news:7w************@sic.twinsun.com... [...] As an aside, the wording in C99 does not seem to specifically rule out the following declaration: enum { foo = INT_MAX, foo_plus_one }; though clearly this violates the intent of the standard, as 'foo_plus_one' is of type 'int'. Certainly no diagnostic is required for this bogus declaration, though I think one ought to be. I think that the intent is to still apply the constaint in the subclause and require a diagnostic: Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by ~~~~~~~~~~~~~~~~~~~~~~~ adding 1 to the value of the previous enumeration constant. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But, if you disagree, how about: 6.6p3 (constraints) Each constant expression shall evaluate to a constant that is in the range of representable values for its type. ? -- Jun, Woong (my******@hanmail.net) Dept. of Physics, Univ. of Seoul Nov 13 '05 #7

 P: n/a In article Jun Woong writes:From the TC2 for C90 ... Aha. You have an advantage over me: I have neither of the two TCs. -- In-Real-Life: Chris Torek, Wind River Systems (BSD engineering) Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: forget about it http://67.40.109.61/torek/index.html (for the moment) Reading email is like searching for food in the garbage, thanks to spammers. Nov 13 '05 #8

 P: n/a "Jun Woong" writes: enum { foo = INT_MAX, foo_plus_one }; I think that the intent is to still apply the constaint in the subclause and require a diagnostic: Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by ~~~~~~~~~~~~~~~~~~~~~~~ adding 1 to the value of the previous enumeration constant. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OK, I guess I can buy that, though it's a little indirect for my taste. Nov 13 '05 #9

 P: n/a In article <7w************@sic.twinsun.com>, Paul Eggert writesAs an aside, the wording in C99 does not seem to specifically rule outthe following declaration:enum { foo = INT_MAX, foo_plus_one }; The intent was that this wording: Each subsequent enumerator with no = defines its enumeration constant as the value of the constant expression obtained by adding 1 to the value of the previous enumeration constant. generates a constant expression (in this case, "foo + 1") to which the constraint applies. I think there was a C90 DR on the topic. -- Clive D.W. Feather, writing for himself | Home: Tel: +44 20 8371 1138 (work) | Web: Fax: +44 870 051 9937 | Work: Written on my laptop; please observe the Reply-To address Nov 13 '05 #10

### This discussion thread is closed

Replies have been disabled for this discussion.