Nick Keighley said:
I found that and thought "implementation defined"
I thought the standard was supposed to list the possible
implementation defined behaviours? Though with a seriously derranged
file system this might not be easy.
It's not the behavior that's implementation-defined, it's the choice
of whether or not the terminating new-line is required. If it's not
required, then the behavior is well-defined; characters written to a
text stream are sent to the stream, whether there's a terminating
new-line or not. If it *is* required, the behavior of a program that
doesn't print the terminating new-line is undefined (simply because
the standard doesn't define it); it could do anything. Plausible
behaviors, among the infinitely many that are allowed:
The last unterminated line doesn't appear in the output file at
all, because writing '\n' is what causes physical output to occur.
The output file could be corrupted and not accessible as a text
file, on a system that distinguishes strongly between text and
binary files.
The output could be written, just as if the new-line weren't
required; the implementers just chose not to guarantee this
behavior.
[...]
Is it that fflush() merely makes it *more likely* the output
will appear? I've used this idiom and had assumed it was
DS 9000 proof.
All output streams with unwritten data are flushed on normal program
termination, so an explicit fflush() just before program termination
doesn't make the output any more likely to appear.
Although if the implementation requires a terminating new-line, and
you haven't written one, then one of the infinitely many possible
behaviors is that fflush() could have some real effect. (On the
DS 9000, it probably *prevents* the output from appearing.)