Article View: comp.std.c
Article #2918Re: Maximum depth of #if preprocessing directives
From: Norman Diamond
Date: Tue, 29 Dec 1992 06:07
Date: Tue, 29 Dec 1992 06:07
71 lines
4375 bytes
4375 bytes
In article <1992Dec29.001933.25655@lucid.com> jss@lucid.com (Jerry Schwarz) writes: >In article <BzsK12.5Ky@jrd.dec.com>, diamond@jit533.jit.dec.com (Norman Diamond) writes: >> In article <JET.92Dec24133237@boxer.nas.nasa.gov> jet@boxer.nas.nasa.gov (J. Eric Townsend) writes: >>>I looked in 2.2.4.1, but I don't recognize any of the translation >>>limits as applying to the maximum depth of #if directives. Could >>>someone tell me where I should look, or if such a limit exists? >>It looks like no such limit exists, so an implementation could set it at 1. >Please justify the claim that compilers can set arbitrary limits >for anything other than the features explicitly mentioned as limitable >by the standard. The standard requires that certain limits (if the implementation imposes such) must be at least as big as certain minima, at least sometimes. It does not require other limits to be at least as big as any particular minima. >On what basis can an implementation justify rejecting >a program that happens to exceed a limit of its devising such a limit. >What constraint or semantic requirement does it violate? The standard doesn't explicitly justify implementations rejecting any program, even when the described possible limits are exceeded. It only implies that such rejection is possible, by listing the limits in the first place. >If a compiler can imposes arbitrary limits, is there any constraint >on the nature of such limits? For example, could I impose a limit on >the number of identifiers containing the sequence "xyyzz". If not why not? No matter how we read the standard, I don't think we'll find an answer to that. I'd suggest getting an interpretation ruling. >Just to put my cards on the table. X3J16/SC22 (C++ standards >committee) is sharply divided on whether to have a section on limits. >[...] we don't want to condone any limits. If I were on the committee, representing myself (as I once did for another language), I would vote against standardizing or condoning limits. >Some of us, including myself, argue that without such a section any limit >is a bug In most languages, complete conformance is probably impossible, and the market tends to set which particulars and to which degrees non-conformance might be excused. For example, in most other languages that have been standardized since around 1970, there is no limit on the length of an identifier and every character is significant -- but I don't know any implementation that will accept a 1-trillion-character identifier. In article <JET.92Dec28174030@boxer.nas.nasa.gov> jet@boxer.nas.nasa.gov (J. Eric Townsend) writes: >My real complaint is twofold: >- there is no documentation of the maximum depth for the compiler in question. The standard appears not to require documentation of limits (except those in the subsequent section, 2.2.4.2 in ANSI Classic). > - the producer of the compiler tends to hide behind ANSI whenever I >complain, so I was looking for *some* sort of guidlines on restrictions. Complain to the ANSI C committee. Also complain with your pocketbook -- if you don't like the product, don't buy it. >I read 2.2.4.1 footnote 8 as meaning "if ansi doesn't have a translation >limit, then please, please, please don't build one into your compiler". I read the footnote as "Please don't build ANY limit into your compiler, not even possibilities listed here." But the footnote doesn't matter. -- Norman Diamond diamond@jit.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Pardon me? Or do I have to commit a crime first?
Technical Details
Message-ID:
<C00Bop.Lss@jrd.dec.com>Path:
arc1-ca.pugleaf.net!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!diamondReferences:
<JET.92Dec24133237@boxer.nas.nasa.gov> <BzsK12.5Ky@jrd.dec.com> <1992Dec29.001933.25655@lucid.com> <JET.92Dec28174030@boxer.nas.nasa.gov>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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 From: diamond@jit533.jit.dec.com (Norman Diamond) Newsgroups: comp.std.c Subject: Re: Maximum depth of #if preprocessing directives Message-ID: <C00Bop.Lss@jrd.dec.com> Date: 29 Dec 92 06:07:37 GMT References: <JET.92Dec24133237@boxer.nas.nasa.gov> <BzsK12.5Ky@jrd.dec.com> <1992Dec29.001933.25655@lucid.com> <JET.92Dec28174030@boxer.nas.nasa.gov> Sender: usenet@jrd.dec.com (USENET News System) Reply-To: diamond@jit.dec.com (Norman Diamond) Organization: Digital Equipment Corporation Japan , Tokyo Lines: 71 Nntp-Posting-Host: jit533.jit.dec.com