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-03-07 18:51 -0800 |
| Organization | None to speak of |
| Message-ID | <87d24k42x4.fsf@kst-u.example.com> (permalink) |
| References | (3 earlier) <mdfbb3$bps$1@dont-email.me> <mdfdil$kg3$1@dont-email.me> <3eLKw.50412$895.40124@fx08.iad> <87wq2s4bmz.fsf@kst-u.example.com> <P4OKw.34683$u24.23323@fx07.iad> |
Richard Damon <Richard@Damon-Family.org> writes:
> On 3/7/15 6:43 PM, Keith Thompson wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>> [...]
>>> I thought that the Translation Limit section gave you an out on
>>> this. While an implementation must accept at least 1 program that
>>> reaches all of the listed limits, the wording is clear that it need
>>> not translate all programs within the translation limits.
>>>
>>> Note that it must "accept" all strictly conforming programs, but as
>>> far as I can see, what that mean is not defined, but it clearly is NOT
>>> the same as "translate" as the implementation is only required to do
>>> this for one program.
>>
>> There have been discussions here before about the distinction between
>> "accepting" and "translating" a program, but I'm still unclear on just
>> what the intended difference is.
>>
>
> Yes, the problem is that the standard is unclear on this, so it makes
> it hard to say anything definitive.
>
>> It seems to me that there's little point in a compiler "accepting" a
>> translation unit if it's not going to generate code for it.
>>
>> Concretely, can anyone cite an example of a real-world compiler
>> "accepting" a translation unit but failing to translate it?
>>
>
> For one, I am not sure if the definition of accept include programs
> with errors. After all, the definition of a strictly conforming
> program is:
> A strictly conforming program shall use only those features of the
> language and library specified in this International Standard. It
> shall not produce output dependent on any unspecified, undefined, or
> implementation-defined behavior, and shall not exceed any minimum
> implementation limit.
>
> That seems to be satisfied by program with a #error directive.
> 1) It is a feature of the standard
> 2) Since the program shall not be translated, it can't run, so it
> doesn't produce any output.
> 3) (I am assuming that it doesn't exceed an implementation limit,
> there are at least some examples that don't)
>
> If a program that has a #error directive is strictly conforming then
> it must be accepted, but it also must not be translated.
The standard says (N1570 4p4):
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.
The definition of "strictly conforming program" doesn't seem to exclude
programs with "#error":
A *strictly conforming program* shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
I'm not quite sure what to make of that. It seems to me that a sensible
definition of "strictly conforming program" *should* exclude anything
with #error -- but it's not obvious that the concept of a "strictly
conforming program" is entirely sensible.
But if there's meant to be a significant difference between "accepting"
and "successfully translating" a translation unit, I presume that
difference would have to apply to things other than the #error
directive.
> I suppose that the one issue is the format of the diagnostic for the
> #error is implementation-define, so that could be the out, but then NO
> program is strictly conforming as ALL compiler output is
> implementation-defined.
It is (or should be) about the behavior of the generated code, not about
the form of the code or of any diagnostic messages.
>>> 4p4 says it must not "translate" but doesn't say it must not "accept"
>>> it. If 4p4 is to mean that an implementation must be able to decide if
>>> any program (within the specified translation limits) fails due to a
>>> #error directive, then I suspect that every current implementation
>>> will fail as you can make the program arbitrarily long so the compiler
>>> will by necessity run out of storage to process the file.
>>
>> A very long program won't necessarily exceed the storage requirements
>> for a compiler. A *complex* program (say, a program with deeply nested
>> constructs) is more likely to do so.
>>
>> [...]
>>
>
> A long program can exceed the memory space of the target processor, or
> even space to output the results (or intermediary files if not
> generating the final output yet).
Perhaps. There are different ways a program can exceed the capacity of
a compiler. The details aren't particularly important to the current
discussion.
--
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