home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3277 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  4.2 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!e2big.mko.dec.com!jrdzzz.jrd.dec.com!jit533.jit.dec.com!diamond
  2. From: diamond@jit533.jit.dec.com (Norman Diamond)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Maximum depth of #if preprocessing directives
  5. Message-ID: <C00Bop.Lss@jrd.dec.com>
  6. Date: 29 Dec 92 06:07:37 GMT
  7. References: <JET.92Dec24133237@boxer.nas.nasa.gov> <BzsK12.5Ky@jrd.dec.com> <1992Dec29.001933.25655@lucid.com> <JET.92Dec28174030@boxer.nas.nasa.gov>
  8. Sender: usenet@jrd.dec.com (USENET News System)
  9. Reply-To: diamond@jit.dec.com (Norman Diamond)
  10. Organization: Digital Equipment Corporation Japan , Tokyo
  11. Lines: 71
  12. Nntp-Posting-Host: jit533.jit.dec.com
  13.  
  14. In article <1992Dec29.001933.25655@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
  15. >In article <BzsK12.5Ky@jrd.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes:
  16. >> In article <JET.92Dec24133237@boxer.nas.nasa.gov> jet@boxer.nas.nasa.gov (J. Eric Townsend) writes:
  17. >>>I looked in 2.2.4.1, but I don't recognize any of the translation
  18. >>>limits as applying to the maximum depth of #if directives.  Could
  19. >>>someone tell me where I should look, or if such a limit exists?
  20.  
  21. >>It looks like no such limit exists, so an implementation could set it at 1.
  22.  
  23. >Please justify the claim that compilers can set arbitrary limits
  24. >for anything other than the features explicitly mentioned as limitable
  25. >by the standard.
  26.  
  27. The standard requires that certain limits (if the implementation imposes such)
  28. must be at least as big as certain minima, at least sometimes.  It does not
  29. require other limits to be at least as big as any particular minima.
  30.  
  31. >On what basis can an implementation justify rejecting
  32. >a program that happens to exceed a limit of its devising such a limit.
  33. >What constraint or semantic requirement does it violate?
  34.  
  35. The standard doesn't explicitly justify implementations rejecting any program,
  36. even when the described possible limits are exceeded.  It only implies that
  37. such rejection is possible, by listing the limits in the first place.
  38.  
  39. >If a compiler can imposes arbitrary limits, is there any constraint
  40. >on the nature of such limits? For example, could I impose a limit on
  41. >the number of identifiers containing the sequence "xyyzz".   If not why not?
  42.  
  43. No matter how we read the standard, I don't think we'll find an answer to
  44. that.  I'd suggest getting an interpretation ruling.
  45.  
  46. >Just to put my cards on the table.  X3J16/SC22 (C++ standards
  47. >committee) is sharply divided on whether to have a section on limits.
  48. >[...] we don't want to condone any limits.
  49.  
  50. If I were on the committee, representing myself (as I once did for another
  51. language), I would vote against standardizing or condoning limits.
  52.  
  53. >Some of us, including myself, argue that without such a section any limit
  54. >is a bug
  55.  
  56. In most languages, complete conformance is probably impossible, and the
  57. market tends to set which particulars and to which degrees non-conformance
  58. might be excused.  For example, in most other languages that have been
  59. standardized since around 1970, there is no limit on the length of an
  60. identifier and every character is significant -- but I don't know any
  61. implementation that will accept a 1-trillion-character identifier.
  62.  
  63. In article <JET.92Dec28174030@boxer.nas.nasa.gov> jet@boxer.nas.nasa.gov (J. Eric Townsend) writes:
  64. >My real complaint is twofold:
  65. >- there is no documentation of the maximum depth for the compiler in question.
  66.  
  67. The standard appears not to require documentation of limits (except those in
  68. the subsequent section, 2.2.4.2 in ANSI Classic).
  69.  
  70. > - the producer of the compiler tends to hide behind ANSI whenever I
  71. >complain, so I was looking for *some* sort of guidlines on restrictions.
  72.  
  73. Complain to the ANSI C committee.  Also complain with your pocketbook --
  74. if you don't like the product, don't buy it.
  75.  
  76. >I read 2.2.4.1 footnote 8 as meaning "if ansi doesn't have a translation
  77. >limit, then please, please, please don't build one into your compiler".
  78.  
  79. I read the footnote as "Please don't build ANY limit into your compiler,
  80. not even possibilities listed here."  But the footnote doesn't matter.
  81. --
  82. Norman Diamond                diamond@jit.dec.com
  83. If this were the company's opinion, I wouldn't be allowed to post it.
  84. Pardon me?  Or do I have to commit a crime first?
  85.