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 1 of 3  [1] 2 3  Next page →

#57948 — What constitutes "standard" C?

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.

[toc] | [next] | [standalone]

#57950

On 3/7/15 1:41 AM, Chad wrote:
> 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.

I'm willing to discuss fork() if you show your version written in 
standard-conforming C. :-)

My version for a cooperative multi-tasking non-hosted embedded package 
can be seen [rolled into schd()] at 
http://www.iedu.com/Solar/LENR/Code.html - but I'm not particularly 
interested in discussing it.

Discussions of linked lists and queues involve looking at the C code for 
the particular mechanism used.

Have you spotted the pattern?

-- 
Morris Dovey

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

#57951

On Saturday, March 7, 2015 at 7:42:02 AM UTC, Chad wrote:
> 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.
>
There are thousands of widely-used libraries written in C, or at least
with C-callable interfaces. If we allowed the ng to become a help / 
discussion group for them all, wed be overwhelmed.

So it's restricted to standard C. But not algorithms - a question of how
to anti-alias a Bezier shape wouldn't be on topic. On the other hand,
some data structures are so basic that "how do you do them in C?"
can't really be ruled off-topic. Linked lists have a little quirk
that the struct tag must be used to declare the next pointer - that's
very topical.

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

#57954

On 07/03/15 10:51, Malcolm McLean wrote:
> Linked lists have a little quirk
> that the struct tag must be used to declare the next pointer - that's
> very topical.

It isn't just linked lists that need the struct tag, but any 
recursively-defined data structure. And there's no getting away from it. 
You just have to use that struct tag inside the declaration, as follows:.

typedef struct listnode_ listnode;

struct listnode_
{
   int n;
   listnode *next;
};

Oh. Maybe you don't need it after all.

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

#57974

On 07/03/15 18:19, Stefan Ram wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>>listnode *next;
>
>    It would be bad style in many cases, but, technically,
>    one can always declare »void * next«.
>

One can, but to no real advantage unless one is implementing 
meta-containers of some kind.

There is a distinct advantage to void * for pointing to the *data*, of 
course. One could in fact do something like this:

typedef struct box_ box;

struct box_
{
   void *data;
   size_t curcap;
   size_t maxcap;
};

You could keep anything you like in a box like that. Then, around that, 
you could wrap all manner of lists, trees, stacks, queues, pqueues, or 
whatever you like.

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

#58018

On 03/07/2015 06:25 AM, Richard Heathfield wrote:
> On 07/03/15 10:51, Malcolm McLean wrote:
>> Linked lists have a little quirk
>> that the struct tag must be used to declare the next pointer - that's
>> very topical.
> 
> It isn't just linked lists that need the struct tag, but any 
> recursively-defined data structure. And there's no getting away from it. 
> You just have to use that struct tag inside the declaration, as follows:.
> 
> typedef struct listnode_ listnode;
> 
> struct listnode_
> {
>    int n;
>    listnode *next;
> };

Since the struct tag and the corresponding typedef name occupy different
namespaces, there's no need for them to be different. Because they
describe the same thing, I think it's better to use the same identifier
for both. Otherwise, you're likely to provoke questions about how they
differ.

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

#58023

On 09/03/15 15:21, James Kuyper wrote:
> On 03/07/2015 06:25 AM, Richard Heathfield wrote:

<snip>

>>
>> typedef struct listnode_ listnode;
>>
>> struct listnode_
>> {
>>    int n;
>>    listnode *next;
>> };
>
> Since the struct tag and the corresponding typedef name occupy different
> namespaces, there's no need for them to be different. Because they
> describe the same thing, I think it's better to use the same identifier
> for both. Otherwise, you're likely to provoke questions about how they
> differ.

There's a reason for it. It's nothing to do with C, though, and 
everything to do with IDEs. I don't know whether it's still the case 
but, in days of yore, using the same identifier for both confused the 
hell out of Visual C++. The compiler had no problem with it, but 
Intellisense grumbled volubly - you had to tell it /which/ listnode you 
meant. Adding the underscore disambiguated the two names for 
Intellisense. And having acquired the habit...

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

#57976

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:b9c13cda-e510-4e36-abf3-1f05b3c82dfd@googlegroups.com...
> On Saturday, March 7, 2015 at 7:42:02 AM UTC, Chad wrote:
>> 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.
>>
> There are thousands of widely-used libraries written in C, or at least
> with C-callable interfaces. If we allowed the ng to become a help /
> discussion group for them all, wed be overwhelmed.
>
> So it's restricted to standard C. But not algorithms - a question of how
> to anti-alias a Bezier shape wouldn't be on topic. On the other hand,
> some data structures are so basic that "how do you do them in C?"
> can't really be ruled off-topic. Linked lists have a little quirk
> that the struct tag must be used to declare the next pointer - that's
> very topical.

comp.unix.programmer

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

#57953

On 07/03/15 07:41, Chad wrote:
> fork() doesn't [constitute standard C] because it's not mentioned in the various C standards.

The question is "what constitutes "standard" C", to which the only 
sensible answer is: C that conforms to a standard.

I think you intended to ask "what is topical in comp.lang.c?" It has 
been said that a C program is acceptable to comp.lang.c if and only if 
it is acceptable to comp.lang.c - which is true but perhaps unhelpful.

My understanding of the topic of this group is that it is about 
programming in the C language. Thus, "how do I do X in C?" is an 
acceptable question (as long as it isn't already answered in the FAQ). 
Of course, the answer might be "you can't do that in C", which is 
probably not literally true but is shorthand for "you would need to use 
an implementation extension". Such questions are better answered in an 
implementation-specific group.

So, for example, you might ask "is there an ISO C equivalent to the Unix 
fork()?" (Answer: no, but it's still a topical question.)

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

#57965

On 03/07/2015 06:21 AM, Richard Heathfield wrote:
...
> The question is "what constitutes "standard" C", to which the only 
> sensible answer is: C that conforms to a standard.

You do remember how the C standard defines "conforming code"? Are you
sure you want to include the Magna Carta as "standard C"?
-- 
James Kuyper

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

#57968

On 07/03/15 16:24, James Kuyper wrote:
> On 03/07/2015 06:21 AM, Richard Heathfield wrote:
> ...
>> The question is "what constitutes "standard" C", to which the only
>> sensible answer is: C that conforms to a standard.
>
> You do remember how the C standard defines "conforming code"? Are you
> sure you want to include the Magna Carta as "standard C"?


Do you have a compiler for it? :-)

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

#57970

On 03/07/2015 12:09 PM, Richard Heathfield wrote:
> On 07/03/15 16:24, James Kuyper wrote:
>> On 03/07/2015 06:21 AM, Richard Heathfield wrote:
>> ...
>>> The question is "what constitutes "standard" C", to which the only
>>> sensible answer is: C that conforms to a standard.
>>
>> You do remember how the C standard defines "conforming code"? Are you
>> sure you want to include the Magna Carta as "standard C"?
> 
> 
> Do you have a compiler for it? :-)

I've thought about writing a minimal fully conforming implementation
that would accept it - but I haven't had the spare time to do so. 4p4 is
the key thing that makes it non-trivial. Somebody must have done so by
now, at least as a joke. There's probably a way to write such an
implementation as a shell script around a perfectly normal
implementation, but the examples I've seen of people trying to do so
don't conform to 4p4 correctly.
-- 
James Kuyper

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

#57977

On 3/7/15 12:47 PM, James Kuyper wrote:
> On 03/07/2015 12:09 PM, Richard Heathfield wrote:
>> On 07/03/15 16:24, James Kuyper wrote:
>>> On 03/07/2015 06:21 AM, Richard Heathfield wrote:
>>> ...
>>>> The question is "what constitutes "standard" C", to which the only
>>>> sensible answer is: C that conforms to a standard.
>>>
>>> You do remember how the C standard defines "conforming code"? Are you
>>> sure you want to include the Magna Carta as "standard C"?
>>
>>
>> Do you have a compiler for it? :-)
>
> I've thought about writing a minimal fully conforming implementation
> that would accept it - but I haven't had the spare time to do so. 4p4 is
> the key thing that makes it non-trivial. Somebody must have done so by
> now, at least as a joke. There's probably a way to write such an
> implementation as a shell script around a perfectly normal
> implementation, but the examples I've seen of people trying to do so
> don't conform to 4p4 correctly.
>

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.

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.

This means that, as far as I can tell, the trivial implementation that 
compares the source file to a limited set of sources, and if it matches 
copies the matching translated version, and if not, "accepts" the 
program and then declares a translation limit violation, is, strictly by 
the standard, conforming.

This isn't really a knock on the standard, as it does provide a good 
definition of a very useful language. It just is that "conformance" is 
really a hard thing to usefully define, and to be truthful isn't what 
most people have as their top requirement (look at how many compilers 
have non-conforming modes, many even the default). I think the committee 
did a reasonable job to provide a reasonable space to work in for decent 
compilers.

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

#57978

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.

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?

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

[...]

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

#57985

Keith Thompson <kst-u@mib.org> 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.
 
> 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.

Well, "accept" could mean that it was legal C, but exceeded some
compiler limit, such as on array sizes. 

There might be cases like:

static char x[1000000000];

where the compiler could generate correct code, but the linker wouldn't
be able to give an an appropriate address, and so fail at link time.

That requires a complicated discussion about compile and link time,
which as far as I know the standard doesn't distinguish.

I might say that "accept" means want lint used to do, which doesn't
include code generation.

> Concretely, can anyone cite an example of a real-world compiler
> "accepting" a translation unit but failing to translate it?

(snip)

-- glen

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

#57988

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.

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.

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

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

#57989

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"

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

#58882

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

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

#58921

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"

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

#58976

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

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

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

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web