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 16:33 -0700
Organization	None to speak of
Message-ID	<87619ops8j.fsf@kst-u.example.com> (permalink)
References	(6 earlier) <87wq2s4bmz.fsf@kst-u.example.com> <P4OKw.34683$u24.23323@fx07.iad> <kfnvbhqdmo8.fsf@x-alumni2.alumni.caltech.edu> <87lhilqdlr.fsf@kst-u.example.com> <kfnr3scadq8.fsf@x-alumni2.alumni.caltech.edu>

Show all headers | View raw

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?

>> 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?
>
> In a nutshell, here is my view:
>
> "accept" is the opposite of "reject".
>
> To "reject" a program means refusing to translate it (as opposed
> to being unable to translate for some other reason) because
> the source does not conform to what the compiler considers
> the minimum extent of the language.
>
> Being unable to translate a program (ie, TU) is not a rejection,
> just a limitation of what the compiler can do.  Any TU not
> explicitly "rejected" (denied translation, as opposed to being
> unable to translate) is "accepted".

If the compiler dies with a fatal error message before it's able to
detect the missing }, has it "accepted" the translation unit?

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

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