Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58921

Re: What constitutes "standard" C?

From Keith Thompson <kst-u@mib.org>
Newsgroups comp.lang.c
Subject Re: What constitutes "standard" C?
Date 2015-03-25 08:52 -0700
Organization None to speak of
Message-ID <87lhilqdlr.fsf@kst-u.example.com> (permalink)
References (4 earlier) <mdfdil$kg3$1@dont-email.me> <3eLKw.50412$895.40124@fx08.iad> <87wq2s4bmz.fsf@kst-u.example.com> <P4OKw.34683$u24.23323@fx07.iad> <kfnvbhqdmo8.fsf@x-alumni2.alumni.caltech.edu>

Show all headers | View raw

Tim Rentsch <txr@alumni.caltech.edu> writes:
> 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.
>> [snip incidental]
>
> Let me suggest that you are overanalyzing this.  The people who
> sign off on wording in the Standard are not language lawyers
> to the degree that posters in comp.lang.c are.  There is a simple
> and consistent plausible interpretation here, to wit:
>
>   1. "accept" means "deem suitable for successful translation",
>      regardless of whether translation can be accomplished
>      successfully (eg, due to an out-of-memory condition);  and
>
>   2. the statement in 4p4 "trumps" the definition in 4p5, so any
>      program with such an #error directive is excluded from the
>      stipulation of 4p6, even if said program were strictly
>      conforming in all other ways.
>
> I admit this proposed interpretation could be argued in a court
> of "language law", if there were such a thing, and maybe even
> successfully.  Despite that it is very likely close to what was
> intended.  And, in any case, the only way to really be sure is
> to submit a Defect Report and get an official statement from
> WG14;  discussion in comp.lang.c might be illuminating about what
> /may/ have been intended, but it is highly unlikely to answer the
> question about what /was/ intended (or, perhaps more importantly,
> what C implementors think was intended).

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?

Narrowing the question slightly, is there a concrete example not
involving the #error directive?  (I find it implausible that #error
would be the only distinction between accepting and translating a
translation unit.)  If a translation unit exceeds the compile-time
memory capacity of an implementation, is the compiler still required to
"accept" it?

-- 
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

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