home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3306 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.5 KB  |  58 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!uunet.ca!geac!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Limits in standard (was: Maximum depth of #if preproc...)
  5. Message-ID: <1992Dec31.193839.1581@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1992Dec29.001933.25655@lucid.com> <C01q3x.Bpp@sneaky.lonestar.org> <1992Dec31.023341.16602@lucid.com>
  8. Date: Thu, 31 Dec 92 19:38:39 GMT
  9. Lines: 47
  10.  
  11. > > > Just to put my cards on the table.  X3J16/SC22 (C++ standards
  12. > > > committee) is sharply divided on whether to have a section on
  13. > > > limits.  Some of us, including myself, argue that without such a
  14. > > > a section any limit is a bug....  we don't want to condone any limits.
  15. > > How can you possibly avoid some kind of limit?
  16. > Of course I'll run out of some resource eventually, but chances
  17. > are it will not translate directly into any of the numbers in
  18. > the standard, and it may vary from run to run. ... My contention
  19. > is that these limits are a quality of implementation issue rather
  20. > than a conformance issue.
  21.  
  22. The C standard does condone limits, but the actual wording is:
  23.  
  24. #  The implementation shall be able to translate and execute at least
  25. #  one program that contains at least one instance of every one of the
  26. #  following limits.  [Footnote: Implementations should avoid imposing
  27. #  fixed translation limits wherever possible.]
  28.  
  29. I believe that the intended thrust of these words in 2.2.4.1/5.2.4.1 is:
  30. "We would really rather that you don't fix limits at all, but IF YOU MUST,
  31. then those limits should be at least as large as the following."
  32.  
  33. Whether fixed limits are an insupportable evil or not is a religious issue,
  34. on which there seem to be three points of view:
  35.  
  36. 1. Fixed limits are so evil that an implementation should be forbidden
  37.    from having them.
  38.  
  39. 2. Fixed limits are so much a quality-of-implementation issue that a
  40.    standard should not be allowed to mention them.
  41.  
  42. (This is the point of view quoted above.)
  43.  
  44. 3. Fixed limits are a quality-of-implementation issue, but ridiculously
  45.    small fixed limits could constrain the programmer so much that the
  46.    standard should prohibit them.
  47.  
  48. (This is the point of view of the C standard, and mine.)
  49.  
  50. Discussion of what the C++ standard should do, of course, belongs in
  51. comp.std.c++ and not here.
  52. -- 
  53. Mark Brader            At any rate, C++ != C.  Actually, the value of the
  54. SoftQuad Inc., Toronto        expression "C++ != C" is implementation-defined.
  55. utzoo!sq!msb, msb@sq.com                -- Peter da Silva
  56.                 [Actually, it's undefined.]
  57. This article is in the public domain.
  58.