Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Are there any conformant C compilers? Date: Fri, 26 Aug 2022 07:51:43 -0700 Organization: A noiseless patient Spider Lines: 94 Message-ID: <86mtbrrrb4.fsf@linuxsc.com> References: <86v8qgs5ww.fsf@linuxsc.com> <87r114w98x.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="afcc7083db196e1e8e1d2e6bebe1e49f"; logging-data="12059"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18v3Jpq6BD17VywU/LE08577arH/9RSWbk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:MqvKztgbYCJNyARHoxx5/HpBRRw= sha1:5t2HR0QmPTU5g0bV3puY+uR3c/c= Xref: csiph.com comp.lang.c:167234 Keith Thompson writes: > Tim Rentsch writes: > >> antispam@math.uni.wroc.pl writes: >> >>> In draft standard (n3047.pdf) I see: >>> >>> : A conforming hosted implementation shall accept any strictly >>> : conforming program. >>> >>> We also have: >>> >>> : A strictly conforming program shall use only those features of >>> : the language and library specified in this document. It shall >>> : not produce output dependent on any unspecified, undefined, or >>> : implementation-defined behavior, and shall not exceed any minimum >>> : implementation limit. >>> >>> Take the following program: [..cut..] >>> >>> Anyway, gcc runs out of memory compiling this program and >>> other C compilers are also likely to run out of memory. >>> [...] >> >> I suspect you are confusing the notion of accepting a program and >> the capability of being able to compile a program successfully. >> The C standard does not say that implementations must be able to >> compile successfully any strictly conforming program, only that >> they must accept them. Not the same thing. At any point in >> compiling a program (assuming a #error directive has not yet been >> seen) a compiler is free to say "I don't yet see anything wrong >> with this program, but it's too large for me to handle." The >> compiler is accepting the program by virtue of not rejecting it. > > As I recall, you have your own definition of "accept" that I was never > able to figure out. In particular, you believe that a compiler can > "accept" a program even if it dies with a stack overflow. > > Can you clarify what you mean by "accept"? I think my point of view is easy to explain: The opposite of "accept" is "reject" (a term not used in the C standard, but that isn't important to this explanation). A compiler (or implementation) "rejects" a program if it refuses to compile the program. That is not if the compiler _is unable_ to compile the program, but only if the compiler _refuses_ to compile the program. Note that a compiler can refuse to compile a program if it can't make sense of the program, as for example if there is a syntax error. Even so, such cases fall into the category of refusing to compile the program, as opposed to, let us say, running out of memory, which falls under the heading of being unable to compile the program, and not of refusing to compile the program. If a compiler doesn't refuse to compile a program then it accepts the program; it's always either one or the other. > If you have the program from the top of this thread, which causes a > compiler to crash, followed by a #error directive, does the compiler > "accept" that program if it never sees the #error directive? I don't think it matters whether that counts as "accepting" the program or not. The rule for a #error directive is only that an implementation cannot _successfully translate_ a program with an (unskipped) #error directive. Whether the compiler explicitly rejects the program (or translation unit), or crashes trying to compile it, the implementation still has not successfully translated the program (or that part of the program). Thus what the C standard decrees is correctly observed. > My impression is that you're warping the meaning of "accept" to force > the requirement that "A conforming hosted implementation shall accept > any strictly conforming program." to make sense. In my opinion, a > compiler that terminates a compilation with a message that it has run > out of memory, or that simply crashes, has not "accepted" the program. > It's impossible to satisfy that requirement in all cases, but most > people accept the intent rather than the literal meaning (though it > might be nice to refine the wording). I believe I understand your reaction. My notion of "accept" is simple, consistent, and easy to understand. Also it gives results that obey what the C standard says, without having to resort to talking about "intent" or "literal meaning". Personally I think that makes it a better fit for the C standard is trying to express. You are welcome to a different point of view if that is your preference. I don't see anything in your statement above that your reaction is anything other than that you have a different opinion.