Path: csiph.com!news.mixmin.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 19:45:17 -0700 Organization: A noiseless patient Spider Lines: 163 Message-ID: <86fshis8ua.fsf@linuxsc.com> References: <86v8qgs5ww.fsf@linuxsc.com> <87r114w98x.fsf@nosuchdomain.example.com> <86mtbrrrb4.fsf@linuxsc.com> <874jxyltz1.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="7e358356b2d532e1bf5d8d8c23833be7"; logging-data="232329"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ETfG8Z5SROxZcevHEYCavKrzHw+Se0m4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:b9g327+rJqffFZtxYDfGdv4AeT8= sha1:VpNugnXvnwQBJNoUZ1AaE48kdDo= Xref: csiph.com comp.lang.c:167242 Keith Thompson writes: > Tim Rentsch writes: > >> 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. > > Thank you for the explanation. I understand what you mean by > "accept", but in my opinion it's ... I don't quite want to say > it's wrong, but it seems at odds with ordinary English usage. If you look up the word "accept" in a few online dictionaries you will find that it has several definitions. Some of those definitions are consistent with the usage I have explained. (Incidentally I have confirmed that view with disinterested third parties.) > If I had not written this response, I hope you wouldn't say > that I have *accepted* your definition. I think you have accepted my comments as reflecting my view, even if your own views are different. A statement can be accepted without agreeing with it. > If an employer offers you a job and you say yes and sign the > paperwork, you've accepted it. If you say no, you've rejected it. > If you do nothing (say, if the offer letter was lost in the mail), > by your definition you've "accepted" the offer. That seems > absurd. The word "accept" has more than one meaning. > "Accept" and "reject" are exclusive, but not exhaustive. It's > entirely possible to neither accept nor reject something. The word "accept" has more than one meaning. So does the word "reject". It seems to me, if a word used in the C standard (and one not defined by the C standard nor in any of the normative references) has more than one meaning, what makes the most sense is to choose the meaning that provides the best fit with how the word is used and how it relates to other passages in the C standard. That is what I've done. Conversely, it seems odd to insist on a different meaning for the word, a meaning that presents difficulties when considered in conjunction with other parts of the C standard. It appears that that is what you have done. > N1570 4p6 says: > A conforming hosted implementation shall accept any strictly > conforming program. > > 1p2 says: > This International Standard does not specify > [...] > - the size or complexity of a program and its data that > will exceed the capacity of any specific data-processing > system or the capacity of a particular processor; > > (And the latest C23 draft has the same wording.) > > My take on this is that 4p6 is not worded quite as precisely as > it could be. [...] My take on this is that you are interpreting passages in the C standard based on your own preconceptions of what the word "accept" means, rather than investigating the matter and accepting the inherent ambiguity of usage in the English language.