Martin Ambuhl said:
Who is Jane? Your mother? Your wife?
Or is that your poor attempt to be funny?
I never made such a claim.
Nor did I claim that you did.
I was pointing out that the data must be written after the fflush().
Please learn some honesty along with the ability to read.
You snipped the entire message without responding to the
contents and accuse me of not being honest or able to read...
Please take your own advice.
Now let's try this again, if you can manage to converse intelligently,
tell me where I'm mistaken. (or you can take the easy way out and
insult me without contributing anything remotely intelligent... again!)
Among the things that the implementation must specify is, according to the
standard,
-- Whether the last line of a text stream requires a
terminating new-line character (7.19.2).
And how do you interpret that?
A line, by definition (which you already quoted later in this message)
consists of 0 or more chars plus a terminating newline.
My interpretation of that statement is: depending on your implementation
the terminating new-line character on the last line may be optional.
Keeping in mind that the terminating new-line is required on all others
I think that's the only way that statement truly can be interpreted.
Now, when writing to stdout using printf() each line written IS the 'last'
line.
consider:
printf("some prompt:");
fflush(stdout);
Is this portable? I think so, but maybe I'm mistaken.
Will it output a 'line'? No, because it's missing the terminating new-line.
It will output a partial line... that being: "zero or more characters plus a
terminating new-line character" sans the new-line character.
Isn't that legal? I think so, but maybe I'm mistaken.
Isn't that one of the purposes of fflush()?
And 7.19.2 tells us
[#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. Characters may have to be added,
altered, or deleted on input and output to conform to
differing conventions for representing text in the host
environment. Thus, there need not be a one-to-one
correspondence between the characters in a stream and those
in the external representation. Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist |
only of printing characters and the control characters
horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last
character is a new-line character. Whether space characters
that are written out immediately before a new-line character
appear when read in is implementation-defined.
Thank you, you've provided the definitions for text streams, and lines.
Once again for review: a line is required to contain a terminating new-line
unless it is the last line, in which case it is implementation defined as to
whether or not it is required. Agreed?
Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It doesn't.
It is obvious to anyone that can actually read that I was referring to
actual conditions in the real world, not about the standard making claims
about them.
I thought the purpose of this group was to talk about the standard and
the claims made by it, no? Did I accidentally stumble into
comp.real.world.claims ???
But while we're on the subject,
Unixes don't typically reset the position of the prompt...
MS windows/dos boxes typically spit out an extra newline when your
application finishes before displaying the prompt.
On what 'real world' condition do you notice this behavior?
But that wouldn't matter to you, since you obviously have not read the
standard at all.
Bits and pieces... a lot of bits and pieces. Never did read the entire
thing
straight through though... I still peruse sections from time to time
though.
Nice piece of documentation to keep handy
Note the wide range of implementation-specific behavior that the text of
the standard (above) does mention.
Yes, but code containing 'implementation-specific' behavior is still
considered 'portable'... no?
If it wasn't then the only true valid definition for main() would have to
be:
int main(void); - no?
5.1.2.2.1
-- If the value of argc is greater than zero, the array
members argv[0] through argv[argc-1] inclusive shall
contain pointers to strings, which are given
implementation-defined values by the host environment
prior to program startup.
I don't presume any such thing. If you are incapable of understanding the
word 'might', then there is no hope for you.
I understand 'might', but that was not the issue... the word in question was
'prompt' .
If you don't presume a terminal, then please explain what you meant by
'prompt'
Good advice. It's time for you totake it, you slimy toad.
Take my own advice?
Let's take another look at the original statements in question.
RG> You need to add a \n to ensure the string is actually printed ME>
return from main is equivalent to calling exit() with value returned.
ME> exit() function must flush all unwritten buffered data.
Do you have an argument with my statement?
Granted, last line may not be (on some implementations) a 'line' but
regardless, it will still be printed.
MA>But he does need to end the the last line of output with a '\n' to have
MA>portable behavior
ME>The behavior of the application is portable with or without the newline.
Again, do you have an argument with my statement? It's quite possible that
the data in question may not be visible on some systems, but that is caused
by something happening 'after' the program in question has completed... not
caused by the behavior of the application as it runs. The application
itself
cannot control what happens when it completes, consider an OS which may
clear the entire terminal upon executing your utility or do away with the
window
completely... does that make your application 'non-portable'... I would
think not.
Mark
