NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/std/c/3302

Internet Message Format | 1992-12-31 | 4.1 KB

Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!bart!volpe
From: [e-mail] (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: Maximum depth of #if preprocessing directives
Message-ID: <[e-mail]>
Date: 31 Dec 92 14:22:13 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: volpe@bart (Christopher R Volpe)
Reply-To: [e-mail]
Organization: GE Corporate Research & Development
Lines: 66
Nntp-Posting-Host: bart.crd.ge.com

In article <[e-mail]>, [e-mail]
(Steve Clamage) gives several excellent arguments against including
translation limits as part of a language standard.

I agree wholeheartedly with Steve. I would prefer to have all implementations
be required to document their individual translation limits, and have any
implementation-imposed translation limit be considered a bug. No
real implementation would be conforming, but implementations could be judged
on how close they come to achieving conformance. As it stands, any compiler
implementor can scream "translation limits!" whenever a bug is reported
to them. In fact, according to the precise wording of the C Standard,
the following program is a valid ANSI C implementation:

    #/bin/csh
    echo "Warning: Dumb-ass compiler"
    echo "Program accepted."

Why is this a conforming implementation? Well, let's look at what the
requirements of a conforming implementation are:

1) Section 1.7 "Compliance" states that "A conforming hosted implementation
   shall accept any strictly-conforming program" (followed by a slight
   relaxation of this for conforming freestanding implementations). One
   might be tempted to define "accept" as "translate and execute", but
   nowhere is "accept" defined this way, and, in fact, defining it this
   way would cause the Standard to contradict itself later in 2.2.4.1.
   So, I define "accept" as printing out "Program accepted". The above
   implementation meets this criteria for all strictly conforming programs
   (as well as any other program, which is fine).

2) Section 2.1.1.3 "Diagnostics" says, "A conforming implementation shall
   produce at least one diagnostic message ... for every translation unit
   that contains a violation of any syntax rule or constraint." The above
   implementation meets this criteria. And, of course, spurious diagnostics
   are allowed.

3) Section 2.2.4.1 "Translation Limits" says, "The implementation shall be
   able to translate and execute AT LEAST ONE program that contains AT LEAST
   ONE instance of every one of the following limits" [emphasis mine] and
   goes on to list the limits. This is the loophole you could pilot an
   aircraft carrier through. Note that it DOESN'T say that it shall
   translate and execute any strictly conforming program that doesn't
   exceed any of the limits. It simply must translate and execute AT LEAST
   ONE program that meets them all. AND THE IMPLEMENTOR GETS TO CHOOSE
   WHICH PROGRAM!!! For my above implementation, I can construct a strictly
   conforming program that contains one instance of each of the translation
   limits, but doesn't print anything out. So, it has no output. I feed it
   to the above implementation (which I claim is an interpreter, and therefore
   need not produce an executable file), which successfully translates and
   executes it, producing no output other than the spurious diagnostic and
   the acceptance indicator. Voila! Instant conformance.

Granted, no one is going to try to market such an implementation, but the
problem is that no matter what "bug" you think you may have found in
an implementation, you can't yell at the vendor claiming non-conformance
because the implementor can say, "Well, yes, our compiler doesn't produce
the correct output for YOUR program, but YOUR program isn't the one we
claim our compiler successfully translates and executes as required by
2.2.4.1. Thanks for calling. Have a nice day."

-Chris
--
==================
Chris Volpe
G.E. Corporate R&D
[e-mail]