Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: What constitutes "standard" C? Date: Sat, 04 Apr 2015 12:15:30 -0700 Organization: None to speak of Lines: 100 Message-ID: <87a8ynyab1.fsf@kst-u.example.com> References: <58082093-9db8-4795-a037-764012b7f76b@googlegroups.com> <3eLKw.50412$895.40124@fx08.iad> <87wq2s4bmz.fsf@kst-u.example.com> <87lhilqdlr.fsf@kst-u.example.com> <87619ops8j.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="32099"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jiOwMMSW5pNtioVgrEeSG" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:P95qbUcYbDkUbxKoKusJkPh0AKQ= sha1:fgJHDtvijJYaq4AnZufuOhPRPP4= Xref: csiph.com comp.lang.c:59594 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: >> [...] >> >>>>>> On 3/7/15 6:43 PM, Keith Thompson wrote: >> [...] >> >>>> So back to my previous question: >>>> >>>>>>> Concretely, can anyone cite an example of a real-world compiler >>>>>>> "accepting" a translation unit but failing to translate it? >>> >>> In a way, yes. Running out of memory during a compile (or to >>> give a perhaps more plausible example, file system full) is a >>> case that counta, I would say, as "accepting" the TU, because >>> it wasn't "rejected". >> >> Suppose we have two nearly identical translation units. Both >> exceed the resource requirements of the compiler; it runs out >> of memory about halfway through. The first is otherwise >> syntaxctically and semantically valid. The second is identical >> except for a missing } at the end. >> >> I'd expect the compiler to behave identically for both, dying >> with a fatal error message when it runs out of memory and >> terminating. It doesn't seem reasonable to expect the compiler >> to continue processing so it can detect the missing }. >> >> Do you think the standard requires it to do so? And, again, do >> you have a concrete example of a real-world compiler making this >> distinction? [...] > To some extent I think we may be talking at cross-purposes here. > I understand the point you are implicitly making (at least I > think I understand the point I think you're making), and it's a > reasonable question from a logical point of view. But I don't > think it's a very imporant question. I believe you are trying to > split semantics hairs that WG14 isn't interested in clarifying. [big snip] I think you're right. I think I've been reading too much into the distinction between "accepting" and "successfully translating". Perhaps I should just stop there (and any readers are welcome to do so), but I'm going to go into the history a bit. In the C90 standard, section 4 is titled "Compliance", and is just 4 paragraphs long. It uses the words "accept" and "acceptable" in reference to programs, not translation units. It doesn't explicitly define the word "accept". Environmental limits are discussed later, in section 5.2.4, but section 4 explicitly says that a program that exceeds "any minimum implementation limit" is not strictly conforming, which implies that it need not be accepted. I see no discussion about how an implementation should behave when a limit is exceeded; I conclude that the behavior is undefined. A compiler crashing without an error message because the input program is too big or complex is perhaps unfriendly, but does not as far as I can tell violate the standard. C99 changed the name of section 4 from "Compliance" to "Conformance" (I see no particular significance in that) and expanded the discussion from 4 paragraphs to 8. Paragraph 4, discussing the newly added #error directive, says: The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion. (6.10.5 additionally requires a diagnostic message.) This is where the phrase "successfully translate" comes into section 4. The words "accept" and "acceptable" are still used only in reference to programs, not to (preprocessing) translation units. A footnote in 5.1.1.3 "Diagnostics", in both C90 and C99, says that an implementation "may also successfully translate an invalid program". The description of #error in section 4 overrides that permission in one specific case. The standard uses the phrase "successfully translate" in reference to preprocessing translation units (source files along with everything they #include), and "accept" in reference to entire programs. "Successful translation" seems to refer only to translation phases 1 through 7 (everything before linking). A program's source files might be successfully translated, but the program as a whole not accepted, if an error is detected at link time. I don't think there's any significant difference between C99 and C11 in this area. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"