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

Groups > comp.lang.c > #57948 > unrolled thread

What constitutes "standard" C?

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#58985

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"

[toc] | [prev] | [next] | [standalone]

#59102

Keith Thompson <kst-u@mib.org> wrote:

(snip)

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

In the days of batch processing, when it might be hours before
you saw the output from the compiler, it was nice of compilers
to generate all the possible messages.  That is, even when it
couldn't generate output to still be able to parse the input and
generate syntax errors, maybe a little more.

But if the compiler gives up on the first error, that probably 
isn't good enough today.

-- glen

[toc] | [prev] | [next] | [standalone]

#59111

W dniu piątek, 27 marca 2015 21:15:06 UTC+1 użytkownik glen herrmannsfeldt napisał:
> Keith Thompson <kst-u@mib.org> wrote:
> 
> (snip)
> 
> > 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 }.
> 
> In the days of batch processing, when it might be hours before
> you saw the output from the compiler, it was nice of compilers
> to generate all the possible messages.  That is, even when it
> couldn't generate output to still be able to parse the input and
> generate syntax errors, maybe a little more.
> 
> But if the compiler gives up on the first error, that probably 
> isn't good enough today.
> 
i can not quite understand how they can not give up on first error.. they just skip one /whole function and go to another ?

-- 
She can talk to squirrels...oh, ho yeah
Coming' back from the convalescent home...Oh...
Staring' at sports cars ... crying'
(beck)

[toc] | [prev] | [next] | [standalone]

#59112

On Saturday, March 28, 2015 at 12:19:43 AM UTC, fir wrote:
> 
> i can not quite understand how they can not give up on first error.. 
> they just skip one /whole function and go to another ?
> 
You sometimes get an error cascade. Particularly if a curly brace
is misplaced, the compiler then gets all the following braces confused
and reports all sorts of strange errors.
But most errors are local, and the compiler can recover. For
example if you type x+ +; instead of x++ then a typical compiler
recognises a stray token, discards everything up to the semicolon, 
and then correctly expects the next statement.

[toc] | [prev] | [next] | [standalone]

#59162

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

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.
Looking at the issue from that point of view, I don't think it's
important for these questions to have absolutely precise answers.
If you want to criticize the Standard for have vague language on
this topic, I would agree that that is a fair criticism.  But
that's not my focus here, which is to understand (and explain)
what interpretation is intended, purely from a pragmatic point of
view.  I don't think anyone really expect any implementation to
be resilient enough to process arbitrarily large source files, as
seems to be implied by the Standard.  And if it can't, is that
the implementation's fault, or the fault of the underlying OS and
hardware?  The Standard specifically identifies the properties of
those things as being outside what the Standard addresses.  So do
we have a conforming implementation on a less-than-capable data
processing system, or do we have a non-conforming implementation
on a fully capable data processing system?  Pragmatically the
distinction is not important.  Similarly for "accept":  if an
implementation outright refuses a strictly conforming TU (eg,
proclaims the compiler has "choosen" not to attempt translation)
then we know the implementation is non-conforming.  Conversely,
if the compiler simply gives up in the middle, there is no
conclusion one way or the other.  At some level there is no way
to prove that an implementation is conforming.  In some cases
though we can show that an implementation is non-conforming, and
that's really what matters.  If hypothetically we had an
implementation that is otherwise fully conforming, but for some
reason would not compile programs on Thursdays, would you call
that a non-conforming implementation?  I wouldn't;  I'd call it a
conforming implementation with a bug in it.  What WG14 cares most
about (along this axis) is whether implementors understand how
WG14 expects and intends the Standard to be read;  as long that
is the case, it doesn't matter if the wording is vague or a
little bit fuzzy.  I know you would prefer to read the Standard
as an independent document that can be read literally and
logically, and I agree that the Standard could do a better job of
doing this than it does now.  In this conversation, however, that
is not my focus.  Rather, it is to allow an operationally useful
interpretation, without concern for a 100% precise definition.

Hopefully this hasn't been just a wasted message...  thank you
for reading (which I am fully confidant you have).

[toc] | [prev] | [next] | [standalone]

#59188

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Hopefully this hasn't been just a wasted message...  thank you
> for reading (which I am fully confidant you have).

I have, and thank you for taking the time to write it.

While composing a reply, I read section 4 of the standard a bit more
carefully than I had before.  I'll give it some more thought and post a
more substantive followup later.

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

[toc] | [prev] | [next] | [standalone]

#59594

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"

[toc] | [prev] | [next] | [standalone]

#59605

Keith Thompson <kst-u@mib.org> wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:

(snip)
>> 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.
 
(snip)

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

and it might have partially written an output object file, which
might cause problems when read in by another program.
 
> 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.

OK, but what is it required not to do when it does not successfully
translate?  Does that mean that it is required not to generate an
object file (assuming that is the normal result)? 
 
> (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.

As an example, though maybe not quite applicable, the OS/360
and successor linkage editor can mark its output "Not Executable"
if certain errors occur. (Most commonly, undefined external
references.) But with the LET option, it will mark the output
"Executable" even with such errors.

Is a compiler non-conforming if it still writes out an object
program that can still be executed, even though it is supposed
to "not successfully translate" the source?

(Of course, it is up to the user to know that unusual things
might happen.)

In the case of unresolved external references, one might know
that a particular reference isn't used, and can ignore the
problem.

-- glen

[toc] | [prev] | [next] | [standalone]

#59643

On 04/04/2015 09:13 PM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
...
>> 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.
> 
> OK, but what is it required not to do when it does not successfully
> translate?  Does that mean that it is required not to generate an
> object file (assuming that is the normal result)?

5.1.1.2 describes "Translation phases". Translation phase 8 is where the
separate translation units that make up a program get linked together
with the C standard library to produce the "program image". Since
translation is not complete until linkage is achieved, translation can
be called "unsuccessful" even if translation phase 8 is the only one
that failed. However, since 4.8p4 describes something that can be
detected during translation phase 4, I'd consider failing only in phase
8 to be a matter of bad design.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#59651

James Kuyper <jameskuyper@verizon.net> wrote:

(snip, someone wrote)
>>>    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.
 
(then I wrote)
>> OK, but what is it required not to do when it does not successfully
>> translate?  Does that mean that it is required not to generate an
>> object file (assuming that is the normal result)?
 
> 5.1.1.2 describes "Translation phases". Translation phase 8 is where the
> separate translation units that make up a program get linked together
> with the C standard library to produce the "program image". Since
> translation is not complete until linkage is achieved, translation can
> be called "unsuccessful" even if translation phase 8 is the only one
> that failed. However, since 4.8p4 describes something that can be
> detected during translation phase 4, I'd consider failing only in phase
> 8 to be a matter of bad design.

OK, but that is a quality of implementation question. 

I thought here we were discussing what it required of an implementation.

To get more specific, consider a unix-like system where the linker 
generates an output file, but doesn't give it the executable attribute.

According to unix, then, it has not been successful, and unix won't
execute the file.

But I can then chmod +x the file, and run it anyway!

It might even do what I wanted it to do, even if it has a #error in it.

Should an implementation try harder to stop me?

-- glen

[toc] | [prev] | [next] | [standalone]

#59656

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> OK, but that is a quality of implementation question. 
>
> I thought here we were discussing what it required of an implementation.
>
> To get more specific, consider a unix-like system where the linker 
> generates an output file, but doesn't give it the executable attribute.
>
> According to unix, then, it has not been successful, and unix won't
> execute the file.
>
> But I can then chmod +x the file, and run it anyway!
>
> It might even do what I wanted it to do, even if it has a #error in it.
>
> Should an implementation try harder to stop me?

Should it?  Absolutely.

Is it required to?  I'd say no.

Realistically, I'd be very surprised if an implementation generated an
image file for a program containing a #error directive, and just left it
non-executable as an excuse to be able to say it wasn't "successfully
translated".  It's far easier just to treat #error as a fatal error and
not even generate an object file.

The standard permits compilers to behave in all sorts of bizarre ways,
just because its not worth the effort to explicitly forbid every
behavior that might not be considered useful or sensible.

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

[toc] | [prev] | [next] | [standalone]

#59664

On 04/05/2015 04:14 PM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
> 
> (snip, someone wrote)
>>>>    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.
>  
> (then I wrote)
>>> OK, but what is it required not to do when it does not successfully
>>> translate?  Does that mean that it is required not to generate an
>>> object file (assuming that is the normal result)?
>  
>> 5.1.1.2 describes "Translation phases". Translation phase 8 is where the
>> separate translation units that make up a program get linked together
>> with the C standard library to produce the "program image". Since
>> translation is not complete until linkage is achieved, translation can
>> be called "unsuccessful" even if translation phase 8 is the only one
>> that failed. However, since 4.8p4 describes something that can be
>> detected during translation phase 4, I'd consider failing only in phase
>> 8 to be a matter of bad design.
> 
> OK, but that is a quality of implementation question. 
> 
> I thought here we were discussing what it required of an implementation.

I mentioned what is required: failure to complete translation, with the
phase during which failure occurs unspecified.

That I choose to discuss an additional closely-related topic is no
legitimate grounds for complaint.

> To get more specific, consider a unix-like system where the linker 
> generates an output file, but doesn't give it the executable attribute.
> 
> According to unix, then, it has not been successful, and unix won't
> execute the file.
> 
> But I can then chmod +x the file, and run it anyway!

I certainly think it would be more appropriate to halt translation at
the earliest possible time, during translation phase 4, and taking the
approach you describe is pretty ridiculous, but I can find no other
fault with that approach.

> It might even do what I wanted it to do, even if it has a #error in it.

That, of course, depends entirely upon what you want it to do.

> Should an implementation try harder to stop me?

I don't see any reason why. It's a tool meant to help you achieve your
goals, not a prison designed to prevent you from straying.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#57955

On 2015.03.07. 8:41, Chad wrote:
> fork() doesn't because it's not mentioned in the various C standards.

It's don't about fork as such,
it's about people who want to stop off-topic posts.
Sadly, they want to achieve that via _more_ off-topic posts.
So this is quote contra-productive.

[toc] | [prev] | [next] | [standalone]

#57958

On 07/03/15 13:03, Lőrinczy Zsigmond wrote:
> On 2015.03.07. 8:41, Chad wrote:
>> fork() doesn't because it's not mentioned in the various C standards.
>
> It's don't about fork as such,

Right.

> it's about people who want to stop off-topic posts.

Where would you draw the line? Do you think we should welcome articles 
on the Eurovision Song Contest, or Gothic architecture, or the urban 
transport policies of the Metropolitan District of South Humberside?

All of these subjects can be considered worthy of discussion, but 
doesn't it make more sense to discuss them in newsgroups devoted to 
those subjects? If you want to ask a question about Gothic architecture, 
doesn't it make more sense to ask that question in an architecture group 
rather than a C programming group? Aren't people who are interested in 
Gothic architecture more likely to subscribe to an architecture group 
than a C group? And so aren't you more likely to get a good answer in an 
architecture group?

What you seem to be suggesting is that it should be okay for everybody 
to discuss everything everywhere.

It may surprise you to learn this, but the subject (of what is topical 
here) has come up before, and the overwhelming consensus was that we 
should stick to ISO C (and, for historical reasons, K&R C). If you care 
enough to do the legwork, you'll find that I myself raised this subject 
some years ago, in the hope of relaxing the limits of acceptability 
somewhat, and I was roundly rebuffed.

> Sadly, they want to achieve that via _more_ off-topic posts.

Discussion of topicality is, alas, topical in any newsgroup. It couldn't 
be any other way, really, unless every group had a meta-group associated 
with it, which would be wasteful of resources.

> So this is quote contra-productive.

Actually, it's quite productive, since it prevents the newsgroup from 
descending into chaos. The comp.lang.c newsgroup remains remarkably 
focussed on its objective, and I would suggest that its survival as a 
useful group is in no small measure due to that focus.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#57959

On 07/03/2015 13:30, Richard Heathfield wrote:
> On 07/03/15 13:03, Lőrinczy Zsigmond wrote:

>> So this is quote contra-productive.
>
> Actually, it's quite productive, since it prevents the newsgroup from
> descending into chaos.

I thought that had already happened...

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#57966

W dniu sobota, 7 marca 2015 15:42:55 UTC+1 użytkownik Bart napisał:
> On 07/03/2015 13:30, Richard Heathfield wrote:
> > On 07/03/15 13:03, Lőrinczy Zsigmond wrote:
> 
> >> So this is quote contra-productive.
> >
> > Actually, it's quite productive, since it prevents the newsgroup from
> > descending into chaos.
> 
> I thought that had already happened...
> 
there is easy way of repairing it: one need to state some on topic threads then focus on it, answer and thats all (easy thing) [but personally i will not contribute as i am overvorked and got a longer break ;/)

a bit worse thing is that when i began to wrote some things here i felt this place has interesting 'aura' (like i was talking with somewhac competent people)  then it was spoiled by insulting and brainless attacks then the 'aura' droped down.. but now it is again not so bad imo
(maybe, hard to say ;\) 

[toc] | [prev] | [next] | [standalone]

#57980

"Bartc" <bc@freeuk.com> wrote in message news:mdf2nq$8e6$1@dont-email.me...
> On 07/03/2015 13:30, Richard Heathfield wrote:
>> On 07/03/15 13:03, Lorinczy Zsigmond wrote:
>
>>> So this is quote contra-productive.
>>
>> Actually, it's quite productive, since it prevents the newsgroup from
>> descending into chaos.
>
> I thought that had already happened...

    Long, long, ago.

[toc] | [prev] | [next] | [standalone]

#57983

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> It may surprise you to learn this, but the subject (of what is topical
> here) has come up before, and the overwhelming consensus was that we
> should stick to ISO C (and, for historical reasons, K&R C). If you
> care enough to do the legwork, you'll find that I myself raised this
> subject some years ago, in the hope of relaxing the limits of
> acceptability somewhat, and I was roundly rebuffed.
[...]

That discussion took place in September 2007, starting with an article
with the subject "Should we broaden the topicality of this group?".

You posted a summary of the results on 2007-10-02, subject "Topicality
discussion - summary".

Looking through my own archives, I see I mentioned this in 2010, and
posted the Google Groups URLs:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/306800faf6c30d43/a642808d3bf37773
http://groups.google.com/group/comp.lang.c/browse_frm/thread/32c4358dc0307344/faa1895ecbce478b

I haven't recently re-read that discussion, but my memory of it matches
yours.

As I wrote in 2010:

    It's interesting to note that many of those who complain most
    loudly about the topicality guidelines being too strict were
    participating in the newsgroup at the time, but did not choose
    to participate in the 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"

[toc] | [prev] | [next] | [standalone]

#57979

Lőrinczy Zsigmond <nospam@for.me> writes:
> On 2015.03.07. 8:41, Chad wrote:
>> fork() doesn't because it's not mentioned in the various C standards.
>
> It's don't about fork as such,
> it's about people who want to stop off-topic posts.
> Sadly, they want to achieve that via _more_ off-topic posts.
> So this is quote contra-productive.

How do you suggest we react to off-topic posts?  Ignoring them is an
option, but I fear that doing so would just encourage more of them.

(By convention, discussions of topicality are considered topical.)

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

[toc] | [prev] | [next] | [standalone]

#57957

W dniu sobota, 7 marca 2015 08:42:02 UTC+1 użytkownik Chad napisał:
> fork() doesn't because it's not mentioned in the various C standards. Then what about data structures like linked lists and sorting algorithms like selection sort? Shouldn't they also be barred from discussion since the various C standards don't cover them also? Just curious because I don't recall anyone here shouting "It's not in the standard" when the topic of linked lists and queues showed up on here.

Imo word standard in the phrase "standard c " id greatly overused here, standard is only coinded to c be compliant between compiler vendors - not to make chaos of versions and that is all the story.. the rest is c

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web