Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: What constitutes "standard" C? |
| Date | 2015-04-04 12:15 -0700 |
| Organization | None to speak of |
| Message-ID | <87a8ynyab1.fsf@kst-u.example.com> (permalink) |
| References | (8 earlier) <kfnvbhqdmo8.fsf@x-alumni2.alumni.caltech.edu> <87lhilqdlr.fsf@kst-u.example.com> <kfnr3scadq8.fsf@x-alumni2.alumni.caltech.edu> <87619ops8j.fsf@kst-u.example.com> <kfniodk7qyb.fsf@x-alumni2.alumni.caltech.edu> |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> 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 <http://www.ghoti.net/~kst>
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
What constitutes "standard" C? Chad <cdalten@gmail.com> - 2015-03-06 23:41 -0800
Re: What constitutes "standard" C? Morris Dovey <mrdovey@iedu.com> - 2015-03-07 02:57 -0600
Re: What constitutes "standard" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-07 02:51 -0800
Re: What constitutes "standard" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-07 11:25 +0000
Re: What constitutes "standard" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-07 18:34 +0000
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-09 11:21 -0400
Re: What constitutes "standard" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-09 16:08 +0000
Re: What constitutes "standard" C? "Bill Cunningham" <nospam@nspam.invalid> - 2015-03-07 15:07 -0500
Re: What constitutes "standard" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-07 11:21 +0000
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-07 11:24 -0500
Re: What constitutes "standard" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-07 17:09 +0000
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-07 12:47 -0500
Re: What constitutes "standard" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-07 17:47 -0500
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-07 15:43 -0800
Re: What constitutes "standard" C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-08 01:03 +0000
Re: What constitutes "standard" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-07 21:02 -0500
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-07 18:51 -0800
Re: What constitutes "standard" C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 16:02 -0700
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-25 08:52 -0700
Re: What constitutes "standard" C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 15:55 -0700
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-25 16:33 -0700
Re: What constitutes "standard" C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-27 20:14 +0000
Re: What constitutes "standard" C? fir <profesor.fir@gmail.com> - 2015-03-27 17:19 -0700
Re: What constitutes "standard" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 17:30 -0700
Re: What constitutes "standard" C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 14:27 -0700
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-28 20:43 -0700
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-04-04 12:15 -0700
Re: What constitutes "standard" C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-05 01:13 +0000
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-04-05 13:43 -0400
Re: What constitutes "standard" C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-05 20:14 +0000
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:28 -0700
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-04-05 17:56 -0400
Re: What constitutes "standard" C? Lőrinczy Zsigmond <nospam@for.me> - 2015-03-07 14:03 +0100
Re: What constitutes "standard" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-07 13:30 +0000
Re: What constitutes "standard" C? Bartc <bc@freeuk.com> - 2015-03-07 14:42 +0000
Re: What constitutes "standard" C? fir <profesor.fir@gmail.com> - 2015-03-07 08:33 -0800
Re: What constitutes "standard" C? "Bill Cunningham" <nospam@nspam.invalid> - 2015-03-07 18:53 -0500
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-07 16:42 -0800
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-07 15:49 -0800
Re: What constitutes "standard" C? fir <profesor.fir@gmail.com> - 2015-03-07 05:13 -0800
Re: What constitutes "standard" C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-07 15:35 +0000
Re: What constitutes "standard" C? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-07 10:49 -0500
Re: What constitutes "standard" C? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-07 10:52 -0500
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-07 11:21 -0500
Re: What constitutes "standard" C? Keith Thompson <kst-u@mib.org> - 2015-03-07 17:10 -0800
Re: What constitutes "standard" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-09 11:32 -0400
csiph-web