program output?

[Richard Bos]

Let's assume an implementation that has documented that the last line
requires a terminating newline character. On such an implementation,
the following program is not correct:

#include <stdio.h>
int main (void) { putchar ('x'); return 0; }

I would have thought the behavior of the program is undefined on such an
implementation. If that is not the case, what is the behavior of the
above program on such an implementation?

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

Richard

 

[Martin Dickopp]

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

I do understand what "implementation-defined" means, but I don't
understand /why/ this is implementation-defined.

The relevant sentence in 7.19.2#2 is: "Whether the last line requires a
terminating new-line character is implementation-defined."

Maybe my understanding of English is faulty, but I would have thought
the above sentence means that the implementation has to choose between
"the last line requires a terminating new-line character" and "the last
line does not require a terminating new-line character".

Why does the sentence imply that in the former case, the implementation
/also/ has to define the behavior if there is no terminating new-line
character, or if it doesn't imply that, what other part of the standard
requires it?

Martin

 

[Arthur J. O'Dwyer]

[N.B: xpost added]

However that implementation defines it; and note that, because this is
implementation-defined, not undefined, the implementation must define
this some way or other _and_ document this choice. So: read your
implementation's documentation for the answer to your question.

And if the implementation's documentation says, "This behavior is
undefined," then it is undefined, right? For precedent, look at the
way implementations define what happens on the overflow of plain
'char' values.

I think this needs clarification. Crossposted to comp.std.c.
One-line summary: What can happen with a program whose output doesn't
end with a newline?

-Arthur

 

[Richard Bos]

I do understand what "implementation-defined" means, but I don't
understand /why/ this is implementation-defined.

The relevant sentence in 7.19.2#2 is: "Whether the last line requires a
terminating new-line character is implementation-defined."

Maybe my understanding of English is faulty, but I would have thought
the above sentence means that the implementation has to choose between
"the last line requires a terminating new-line character" and "the last
line does not require a terminating new-line character".

Why does the sentence imply that in the former case, the implementation
/also/ has to define the behavior if there is no terminating new-line
character, or if it doesn't imply that, what other part of the standard
requires it?

Good point. IYAM, mere decency would dictate that this should not cause
any unpleasant effects beyond what is strictly documented, and that
"whether it needs... is i-d" includes "and what happens if not is also
i-d", but I agree that this is not made explicit.

Richard

 

[Dan Pop]

Sure, technically this (and all the rest of it) may be correct. I responded
from an exam question standpoint: "What will it do?" (IOW, "What does it do
for the instructor?"), rather than "What does the Standard say?" (applying
the usual rigor expected for answers to general questions in this group).

What makes you think the two answers are any different?

I should have prefaced my response accordingly.

You have actually explained what the instructor expected from the program.
Such an explanation is downright misleading without pointing out the
flaws in his reasoning.

Dan

 

[Leor Zolman]

What makes you think the two answers are any different?

I have to explain the difference between "What will it do on [your/my]
machine?" vs. "What does the Standard say about this?" ??

You have actually explained what the instructor expected from the program.
Such an explanation is downright misleading without pointing out the
flaws in his reasoning.

His "reasoning" evidently includes domain-specific preconditions about the
platform in use, size of a char, and perhaps even signed-ness of a char.
Given a tacit conspiracy by everyone in the classroom to assume those
preconditions, his reasoning wasn't necessarily flawed.

The next time I teach a C class, there's a good chance some, or even most,
of the issues involved here will not come up. It's just a matter of
choosing one's battles in the theater of time constraints.
-leor

 

[j0mbolar]

Not really: the code invokes undefined behaviour at least once, by calling
printf without a proper declaration in scope, so it is not even worth
analysing it: anything can legally happen.

How do you figure? I see 6.5.2.2#6 says the default argument
promotions occur but it does not mention undefiend behavior
in this case.

First of all, the default "signedness" of the char type is
platform-dependent. If it is 8 bits and "signed", as is the default on
typical PC-based platforms, then this does indeed go into an infinite loop.

Can we have a chapter and verse for that? I naively thought that signed
overflow results in undefined behaviour...

In that case, the range of values for an 8-bit char is -128 to +127.

Can we have a chapter and verse for that? I naively thought that the
standard only guaranteed -127 to 127 and that sign-magnitude and one's
complement implementations are perfectly OK...

It will always be less than +128.

True, but by the time it makes the transition from 127 to whatever value
(if any), anything can happen... including getting out of the loop.

If the default for chars is unsigned, then the program output is 258 [I
didn't figure it out, I just ran it ;-) ]

Maybe, maybe not. As the last line of output is not newline terminated,
there is no guarantee that the program will produce any output at all
(it's an implementation-defined feature).

Whoever wrote this test expecting another answer than "undefined
behaviour" should better start learning C...

Here's a properly rewritten version of this test:

Assuming 8-bit bytes, what is the output of the following program?

#include <stdio.h>

int main()
{
unsigned char ch;
unsigned int i = 2;

for (ch = 0; ch < 256; ch++) i += 2;
printf("%u\n", i);
return 0;
}

Note that if i is plain int, signed overflow will occur inside the
infinite loop, and all the bets are off, again.

Dan

 

[Eric Sosman]

How do you figure? I see 6.5.2.2#6 says the default argument
promotions occur but it does not mention undefiend behavior
in this case.

Read the paragraph again, with special attention to the
fifth sentence.

 

[Sam Dennis]

How do you figure? I see 6.5.2.2#6 says the default argument
promotions occur but it does not mention undefiend behavior
in this case.

Read on in the same paragraph:

`If the function is defined with a type that includes a prototype, and
either the prototype ends with an ellipsis [...], the behaviour is
undefined.' (Note that we're now talking about the definition, not the
type of the expression denoting the function to be called.)

printf, obviously, is such a function.

 

[Douglas A. Gwyn]

And if the implementation's documentation says, "This behavior is
undefined," then it is undefined, right?

No, "implementation defined" behavior involves a choice
between well-defined behaviors, and the implementation
shall document which choice it makes.

 

[Martin Dickopp]

No, "implementation defined" behavior involves a choice
between well-defined behaviors, and the implementation
shall document which choice it makes.

Since only a part of this thread has been x-posted to comp.std.c, please
allow me to clarify what the issue was. Please consider 7.19.2#2:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]

Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character? If so, does such a requirement follow from
the above quoted wording, or from some other text in the standard?

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Martin

 

[Dan Pop]

What makes you think the two answers are any different?

I have to explain the difference between "What will it do on [your/my]
machine?" vs. "What does the Standard say about this?" ??

You have actually explained what the instructor expected from the program.
Such an explanation is downright misleading without pointing out the
flaws in his reasoning.

His "reasoning" evidently includes domain-specific preconditions about the
platform in use, size of a char, and perhaps even signed-ness of a char.
Given a tacit conspiracy by everyone in the classroom to assume those
preconditions, his reasoning wasn't necessarily flawed.

I thought it was supposed to be a question about a C program, not about
an unspecified implementation...

If it's a question about a C program, your answer is downright wrong,
period.

Dan

 

[Leor Zolman]

I thought it was supposed to be a question about a C program, not about
an unspecified implementation...

If it's a question about a C program, your answer is downright wrong,
period.

The OP asked about "program output type". What does the Standard have to
say about /that/? ;-)
-leor

 

[Dan Pop]

The OP asked about "program output type". What does the Standard have to
say about /that/? ;-)

Few things are lamer on Usenet than invoking someone's poor command of the
English language...

The subject line of the thread is clear enough, though.

Dan

 

[Leor Zolman]

Few things are lamer on Usenet than invoking someone's poor command of the
English language...

It never even occurred to me that he had poor command of the English
language. His post looks better in that regard than some (perhaps more than
just some) of my own ;-)

So here's where I think we stand. I'm saying I cannot tell whether the OP
was asking "What does the Standard say about what the output should be", as
you interpret the question (and it is certainly a reasonable
interpretation, especially since that's the core flavor of question this
group deals with day-to-day), or if he's really asking, "How was I
supposed to predict what the output of this program would be on our class
platform?" which, given the quality of the question, strikes me as more
likely to reflect actual intent of the instructor. But of course, I don't
know.
-leor

 

[Arthur J. O'Dwyer]

Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character?

No, only whether the last line requires a terminating new-line
character needs to be documented.

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Yes, [...]

FWIW, this is in direct contradiction to the opinion you stated two
messages upthread. Consider it evidence that this area of the Standard
could use some better wording.

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. If the implementation documents that the behavior is
undefined, then it is allowed to do anything with the program (obviously).

[Again I mention the similarity to plain-char-overflow, another
situation in which it is implementation-defined whether or not the
behavior is undefined.]

-Arthur

 

[Douglas A. Gwyn]

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]
Let's assume an implementation that makes the choice (and documents it)
that the last line requires a terminating new-line character. Is such
an implementation required to also define and document the behavior of a
program which writes to a text stream without terminating the last line
with a new-line character?

No, only whether the last line requires a terminating new-line
character needs to be documented.

Otherwise, can it be assumed that the behavior of such a program is
undefined on such an implementation, since lack of explicit definition
of behavior in the standard means undefined behavior (4#2)?

Yes, and more importantly, if the program behavior depends on
whether or not the last line of an input text stream has a
trailing new-line, it is not a strictly conforming program.
(This is a common bug.)

 

[Eric Sosman]

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. [...]

There are certainly more than two possibilities. For
example, here's a third: "An un-terminated line will not
appear on the output stream at all."

fputs("Hello,\nworld!", stdout);
exit(0);

.... could be defined to produce "Hello,\n" and nothing else.
(This is a plausible behavior for a record-oriented file
system.)

 

[Dave Hansen]

On Wed, 26 May 2004 10:01:42 +0200, Martin Dickopp

[...]

Since only a part of this thread has been x-posted to comp.std.c, please
allow me to clarify what the issue was. Please consider 7.19.2#2:

| A text stream is an ordered sequence of characters composed into
| lines, each line consisting of zero or more characters plus a
| terminating new-line character. Whether the last line requires a
| terminating new-line character is implementation-defined. [...]

Interesting. Since the first occurrence of the word "lines" is in
italics, that sentence must be defining what a "line" is. From my
pedantic-mode reading, a "line" includes the terminating new-line by
definition -- otherwise, it's not a "line."

So if the last line doesn't have a terminating new-line it's not a
line. Since it's presumably the last (zero or more) characters in the
stream, the previous line must be the last line. And _it_ does have a
terminating new-line...

Unless the last line is the first line, in which case, there is no
previous line, and therefore no lines at all. Can a text stream have
zero lines? The above definition does not seem to forbid it
("composed into" rather than "composed of").

OK, OK, just having a little fun. But perhaps the last sentence would
be better worded "Whether a text stream requires a final terminating
new-line character..." because it seems (fairly) obvious that is what
is meant. I thought it might be fixed by changing the first sentence
to "...each line separated from the next by a new-line character," but
that would mean the last line could not possibly be terminated by a
new-line...

Regards,

-=Dave

 

[Arthur J. O'Dwyer]

On Wed, 26 May 2004, Douglas A. Gwyn wrote:

As I understand the Standard's intent: An implementation must document
the behavior of a program whose output does not end in a newline, in
one of two ways: either that the output is printed, or that the behavior
is undefined. [...]

There are certainly more than two possibilities. For
example, here's a third: "An un-terminated line will not
appear on the output stream at all."

I tried and failed to find C&V for something along the lines of
"An implementation is allowed to document its behavior in certain
cases that would otherwise be undefined." In any event, "not
appearing" is certainly a valid effect of undefined behavior,
regardless of whatever the implementation documentation says or
doesn't say.

-Arthur