home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3036 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.3 KB  |  47 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!utcsri!geac!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Re: Idle Questions about ANSI C
  5. Message-ID: <1992Nov19.071410.14307@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1992Nov17.123803.6400@thunder.mcrcim.mcgill.edu> <1992Nov17.155826.15087@sq.sq.com> <1992Nov17.205344.20279@blaze.cs.jhu.edu>
  8. Date: Thu, 19 Nov 92 07:14:10 GMT
  9. Lines: 36
  10.  
  11. > > The wording of section 3.1.2.5/6.1.2.5 of the standard clearly implies
  12. > > that the 9 "usual" integral types are the only ones.  They consist of
  13. > > 4 signed integer types, 4 unsigned integer types, and char -- which
  14. > > of course can be either signed or unsigned.  Since size_t and ptrdiff_t
  15. > > are specified respectively as unsigned or signed *integral* types, not
  16. > > *integer* types, then an implementation could actually use char for
  17. > > one of them ...
  18. > 
  19. > To get nitpicky, section 3.3.3.4 states that size_t is an
  20. > unsigned integral type.  Section 3.1.2.5 discusses the integral
  21. > types.  As I read it, no matter what its implementation, char is 
  22. > neither an unsigned integral type nor a signed integral type.  Thus,
  23. > there are 4 possibilites for size_t and ptrdiff_t.
  24.  
  25. Well, I'll back off part way.
  26.  
  27. The standard defines the terms "signed integer type", "unsigned integer
  28. type", and "integral type", but it does not define "signed", "unsigned",
  29. "signed integral type", or "unsigned integral type".  Therefore these
  30. terms mean what they look like, and an integral type that is signed
  31. is a signed integral type.
  32.  
  33. Values of char can be "treated as either signed or nonnegative integers".
  34. In the first case, char *is* therefore a signed integral type, and could
  35. be the type of ptrdiff_t.  However, since the second case does not use
  36. the word "unsigned", it might be argued *not* to imply that char is then
  37. an unsigned type; in particular, it might not have the "cannot overflow"
  38. semantics that unsigned integer types do.  (I think it would need an
  39. Interpretation Ruling to settle this.)  So even in an implementation where
  40. char is not signed and is big enough, it might not be legitimate for it
  41. to be size_t.
  42. -- 
  43. Mark Brader, Toronto        "It's the almost correct solutions that
  44. utzoo!sq!msb, msb@sq.com     are the most dangerous..."  -- Dave Eisen
  45.  
  46. This article is in the public domain.
  47.