program output?

[Wojtek Lerch]

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

An implementation is allowed to do anything it wants to, as long as it
doesn't violate any requirements of the standard. The standard doesn't
forbid documenting anything, does it?

 

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

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.

"Upon further review," as they say in Murkin football, I
think you may be right. 3.4.1 tells us that implementation-
defined behavior is a subset of unspecified behavior, and 3.4.4
says the latter involves a choice from among two or more
possibilities described in the Standard.

7.19.2/2 says it's implementation-defined whether the final
line does or does not require a terminating newline, and 3.4.1
says the implementation must document its choice. Nothing says
what happens if the implementation chooses "The newline is
required" and the program tries to violate the requirement, so
the behavior thereafter is undefined because the Standard
imposes no requirement (3.4.3).

... which leads to an interesting clash between Standardese
and ordinary English. If the implementation goes on to describe
what happens if the program omits the required newline ("A newline
is synthesized from thin blue air," say), this implementation-
provided definition does not "define" the behavior! We're still
in 3.4.3 territory because the implementation's definition doesn't
meet the requirements of 3.4.4 by making a choice among Standard-
specified behaviors. The behavior is defined by the implementation,
but is not implementation-defined.

Counter-intuitive, but eventually understandable. "After great
pain a formal feeling comes."

 

[Keith Thompson]

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

I think that's sufficiently obvious that it doesn't need to be stated.
An implementation can document anything it wants to.

On the other hand, in cases where an implementation is required to
document its behavior, it has to follow its own documentation. If an
implementation chooses to document behavior that the standard leaves
undefined, and then doesn't behave as its own documentation specifies,
I'd say that's not a violation of the standard.

Some concrete examples:

Plain char can be either signed or unsigned. If an implementation
makes plain char signed, but its documentation says it's unsigned,
that's a violation of the standard.

Behavior on signed integer overflow is undefined. If an
implementation's documentation says that signed integer overflow wraps
around, but it actually causes a trap, that's not a violation of the
standard (but it's certainly a flaw -- one that could be corrected
simply by removing the statement from the documentation).

In any event, "not
appearing" is certainly a valid effect of undefined behavior,
regardless of whatever the implementation documentation says or
doesn't say.

Agreed.

 

[Joe Wright]

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

Well, even if the requirement for trailing new-line is documented by
the implementation, who exactly is the requirement binding upon? The
programmer or the implementation? For example:

FILE *t = fopen("text.txt", "w");
fprintf(t, "Hello world");
fclose(t);

I suppose I have written eleven characters to text.txt and nothing
else. And so it would not be a line because the required '\n' is not
there. And perhaps not even a stream for the same reason. Again, who
is this requirement incumbent upon?

I have a Windows98 system. I open this file with a text editor,
change the w to W and save it.

EDIT.COM doesn't complain about missing '\n' but adds it saving.
notepad.exe doesn't complain and doesn't add it.
vim.exe declares [Incomplete last line] and adds '\n' saving.
wordpad.exe doesn't complain and doesn't add it.
winword.exe doesn't complain about missing '\n' but adds it saving.

As a C programmer of applications and utilities, I write text files
in lines ending in '\n'. Even the last one. I do not place this
restriction on people sending files to me. I will see the last line
as a line whether it has a '\n' or not.

Sorry to be so wordy. I suppose that the requirement for a
terminating '\n' or not, documented or not is not actually imposed
on anyone. I suppose it is a caveat only so that I (programmer) can
take care to the case when it isn't there. I suppose also that there
is no case for the last line not ending in '\n' is a requirement.

 

[CBFalconer]

.... snip ...

Well, even if the requirement for trailing new-line is documented
by the implementation, who exactly is the requirement binding
upon? The programmer or the implementation? For example:

FILE *t = fopen("text.txt", "w");
fprintf(t, "Hello world");
fclose(t);

I suppose I have written eleven characters to text.txt and
nothing else. And so it would not be a line because the required
'\n' is not there. And perhaps not even a stream for the same
reason. Again, who is this requirement incumbent upon?

Now precede the fclose(t); line with:

fflush(t);

and I believe the line needs to be written without the \n.

In actual practice I think the standards provision allows for the
fact that, without a final \n (or fflush), the final data may be
left in an internal buffer, and may simply get discarded.

 

[Thad Smith]

... which leads to an interesting clash between Standardese
and ordinary English. If the implementation goes on to describe
what happens if the program omits the required newline ("A newline
is synthesized from thin blue air," say), this implementation-
provided definition does not "define" the behavior!

It does for that particular implementation, but not for the Standard.

We're still
in 3.4.3 territory because the implementation's definition doesn't
meet the requirements of 3.4.4 by making a choice among Standard-
specified behaviors. The behavior is defined by the implementation,
but is not implementation-defined.

It's a matter of perspective. With respect to the Standard, the
behavior might be defined, implementation-defined, unspecified, or
undefined. With respect to the a particular implementation, behavior
can be defined, unspecified (chosen for bounded possibilities), or
undefined. Any constructs which are unspecified or undefined
by the Standard can, of course, be defined for individual
implementations.

Counter-intuitive, but eventually understandable. "After great
pain a formal feeling comes."

Undefined by the Standard, but defined by the implementation seems a
straight-forward (and useful) concept to me.

Thad

 

[Thad Smith]

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

Well, even if the requirement for trailing new-line is documented by
the implementation, who exactly is the requirement binding upon? The
programmer or the implementation?

It is a requirement for the programmer. If it is violated, then the
program hasn't created a proper text stream.

If it were a requirement on the implementation, it would state that when
the stream is closed, if a new-line character were not the last
character one would be added (or maybe that the characters after the
last new-line would be deleted ;-). Sort of like the explicit
gratuitous return 0 for main.

Thad

 

[Dan Pop]

Now precede the fclose(t); line with:

fflush(t);

and I believe the line needs to be written without the \n.

Considering that fclose(t) will flush the stream, it is downright foolish
to believe that preceding it with a fflush(t) is going to make any
difference.

The only reason for calling fflush on a stream before fclose is to be
able to check its return value and take whatever actions are appropriate
in case of failure.

Dan

 

[Douglas A. Gwyn]

FWIW, this is in direct contradiction to the opinion you stated two
messages upthread.

No, and actually I don't recall posting previously about
documenting the requirement for a new-line.

Perhaps you were referring to my pointing out that
"implementation defined" involves a choice among valid
alternatives stipulated in the standard, which does not
allow an implementor to choose "undefined behavior"
(unless that is explicitly one of the allowed choices).
There is no contradiction there.

 

[Douglas A. Gwyn]

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

...

I didn't say that, and in fact I disagree with it.
Please be more careful in your attributions.

 

[Douglas A. Gwyn]

Well, even if the requirement for trailing new-line is documented by the
implementation, who exactly is the requirement binding upon? The
programmer or the implementation? For example:
FILE *t = fopen("text.txt", "w");
fprintf(t, "Hello world");
fclose(t);
I suppose I have written eleven characters to text.txt and nothing else.
And so it would not be a line because the required '\n' is not there.
And perhaps not even a stream for the same reason. Again, who is this
requirement incumbent upon?

It is a requirement imposed on the programmer.
For portability you must assume that a trailing
new-line is always necessary when writing a text
stream, and that the last line might not have a
trailing new-line when reading a text stream.

On some systems, your example would produce no
output (the "partial line" would be discarded).

 

[Joe Wright]

Joe Wright wrote:

... snip ...



Now precede the fclose(t); line with:

fflush(t);

and I believe the line needs to be written without the \n.

In actual practice I think the standards provision allows for the
fact that, without a final \n (or fflush), the final data may be
left in an internal buffer, and may simply get discarded.

From N869..

[#2] The fclose function causes the stream pointed to by
stream to be flushed and the associated file to be closed.
Any unwritten buffered data for the stream are delivered to
the host environment to be written to the file; any unread
buffered data are discarded. The stream is disassociated
from the file. If the associated buffer was automatically
allocated, it is deallocated.

No need for fflush() before fclose().

 

[Dan Pop]

It never even occurred to me that he had poor command of the English
language.

OK, let's have a look again:

I took a test on C.
there was an objective question for program output type.
following is the program:
<snip>
i wrote the answer 256 will be printed.
But our instructor told me that it will be infinite loop.
Is that right, I am not sure of the answer.

If this reflects a good command of the English language, then I don't
even want to see one that, in your opinion, doesn't. In particular, the
sentence:

there was an objective question for program output type.

doesn't make any sense alone. It the rest of the post that clarifies that
the OP wanted to know what is the intended output of a certain program.
And, since he posted the question in c.l.c, it is more than reasonable to
assume that he wanted the answer from the language point of view;
otherwise a newsgroup dedicated to programming on his platform
(whatever that was) was the natural choice.

His post looks better in that regard than some...

I agree that I have seen worse, yet this doesn't make this one look good.

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.

How do you explain the fact that all the other regulars interpreted it in
the context of the newsgroup and only you managed to find a different
interpretation?

Dan

 

[CBFalconer]

... snip various ...

How do you explain the fact that all the other regulars
interpreted it in the context of the newsgroup and only you
managed to find a different interpretation?

Obviously he is a free spirit, thinking "outside the box"

 

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

...

I didn't say that, and in fact I disagree with it.
Please be more careful in your attributions.

Actually, my error was one of incomplete snippage
rather than of misattribution (count the >'s). Sorry
for the confusion.