home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3258 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.5 KB
  1. Path: sparky!uunet!world!ksr!jfw
  2. From: jfw@ksr.com (John F. Woods)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Compatability of enum types and integer types
  5. Message-ID: <20361@ksr.com>
  6. Date: 22 Dec 92 16:52:28 EST
  7. References: <1992Dec21.225604.18749@netcom.com> <Bzn05H.nq@jrd.dec.com>
  8. Sender: news@ksr.com
  9. Lines: 61
  10.  
  11. diamond@jit533.jit.dec.com (Norman Diamond) writes:
  12. >In article <1992Dec21.225604.18749@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
  13. >>The ANSI C standard says (in 3.5.2.2):
  14. >>    "Each enumerated type shall be compatible with an integer type;
  15. >>    the choice of type is implementation-defined."
  16. >>I interpret it to mean that there *must* exist some integer type `T' such that
  17. >>        enum E { red, green, blue } object;
  18. >>        enum E object;
  19. >>        T object;
  20. >>... is a valid translation unit.
  21. >>The person on the other side of this discussion seems to be claiming that
  22. >>[...] the implementation may "put the fix in" so that no matter what type
  23. >>you try to use for `T', the implementation will say "Sorry.  You guessed wrong
  24. >Being implementation-defined means that it must be documented.  Regarding
  25. >some other implementation-defined matters (e.g. which of two possible results
  26. >is obtained from the % operator) most of the regulars in this newsgroup seem
  27. >to feel that the implementation must define a result that is identical over
  28. >all usages.  This kind of opinion suggests that the documentation must tell
  29. >you which type you can use for `T'.
  30. >My opinion is that the documentation can tell you that the implementation
  31. >plays dirty pool.  However, I seem to be a minority of 1.
  32.  
  33. I think you're a minority of two.  I can't see any way for a program to make
  34. use of this in a way that exposes the type yet is guaranteed.  I think one
  35. can argue that
  36.  
  37.     enum thing { small, big=INT_MAX };
  38.  
  39. is required to be compatible with a type no shorter than int, but that still
  40. leaves long (and, actually, if all the integral types are the same size, it
  41. could *still* be compatible only with char).  I think a definition of
  42.  
  43.     Enumeration types are compatible with "int", unless an object in
  44.     a translation unit is declared as an enumeration type and as an
  45.     "int" in the same translation unit or a different translation unit
  46.     at link time, in which case enumeration types are compatible with
  47.     "long".
  48.  
  49. meets all the requirements present in the standard.  (There are certainly other
  50. instances of "implementation-defined behavior" where there is no particular
  51. requirement that the behavior be useful or desirable).  I think it's pretty
  52. clear that the type compatibility of enumerations need *not* be identical
  53. over all usages:
  54.  
  55.     enum boolean { true, false };    /* can be compatible with char */
  56.     enum wider { base, figure = 257 };/* can't be compatible with
  57.                        * 8-bit char but can be short */
  58.     enum widest { small, big = INT_MAX }; /* must be an int, except when
  59.                          "shorter" types are the same
  60.                           size as int */
  61.     enum oops { small, wrong = LONG_MAX }; /* violates a constraint unless
  62.                           int and long are the same
  63.                           size */                        
  64. It might be argued, however, that since the Standard could merely have said
  65. that enumerations are integral types, but are not *compatible* with any
  66. integral types, that there is an implicit requirement that one be able to
  67. take advantage of that type compatibility.  The Rationale, alas, sheds no
  68. light on the matter.  I think the compatibility requirement only buys one
  69. the ability to pass enumerations to functions expecting integral types with
  70. some hope of portability (though I suspect that if enumerations can be
  71. unsigned types, it opens an even larger can of worms).
  72.