🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #2918

Re: Maximum depth of #if preprocessing directives

#2918
From: Norman Diamond
Date: Tue, 29 Dec 1992 06:07
71 lines
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!diamond
References: <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