Please Explian

[manochavishal]

Hi,

int main(int argc, char **argv)
{
int j;
printf("Word id %s",argv[1]);

}


This never used to happen.

I have always seen people saying that use \n in printf statement ie
printf("Hello\n");
as it works out as fflush but i never paid attention.

But this time my prog was not printing what it was suppose to print .
But i used '\n' and it printed.
Can anybody explain why we should use this in *detail* . As i want to
know the *detail* reason for this behaviour.

Thanx in advance.

 

[Walter Roberson]

int main(int argc, char **argv)
{
int j;
printf("Word id %s",argv[1]);
}

This never used to happen.

Wot, you never used to write code that relies upon the value of
argv[1] without first checking to see that argc >= 2 ?

I have always seen people saying that use \n in printf statement ie
printf("Hello\n");
as it works out as fflush but i never paid attention.

But this time my prog was not printing what it was suppose to print .
But i used '\n' and it printed.
Can anybody explain why we should use this in *detail* . As i want to
know the *detail* reason for this behaviour.

The C standard *allows* implementations to not produce the last
line of a text stream when the last line is not terminated with \n .
This is the case whether or not the stream is fflush()'d, and
is the case whether or not the stream is explicitly close()'d.

Whether a particular implementation has this property or not is
implementation-specific, and the implementation could have any
reason for it. An implementation could even handle things this
way just to be perverse, or might do it deliberately in order
to encourage students to learn this detail of C.

You did not mention which platform you are using or which software
version, so we cannot tell you why -your- platform does things
the way it does. And since you asked for "*detail*", if you
had specified the platform, we would have told you to go ask
in a newsgroup that specializes in that platform.

So, no detail here. But I will say that sometimes it only *looks*
like the last line not being produced, when actually the last
line -is- produced but the command prompt then visually
overwrites the last line.

 

[Keith Thompson]

The C standard *allows* implementations to not produce the last
line of a text stream when the last line is not terminated with \n .
This is the case whether or not the stream is fflush()'d, and
is the case whether or not the stream is explicitly close()'d.

I don't think the C standard is even that specific.

C99 7.19.2p2 says:

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.

As far as I can tell, the standard gives no hint about what happens if
the last line "requires" a terminating new-line and the program
doesn't provide one. The worst thing that's *likely* happen on most
implementations is that the last line doesn't appear, but I think it's
actually undefined behavior. I can imagine scenarios where you'd get
only part of the last line, or even where the resulting text file is
malformed. (Think about systems where a text file is represented as a
sequence of records rather than as a stream of characters.)

The standard *could* have nailed this down more precisely. For
example, it could have said something like this:

... Whether the last line requires a terminating new-line
character is implementation-defined. If it does, closing the file
writes a new-line to the stream if the last character written to
the stream was not a new-line.

This would allow a text file with no terminating new-line to be
created on systems that don't require it, while guaranteeing (barring
errors) a properly terminated file on systems that do require it.

In fact, I'd be (mildly) surprised if there were any real-world
implementations that don't already follow this suggested requirement.
But since it's not in the standard, we can't depend on it if we want
maximally portable code.

 

[Keith Thompson]

Keith Thompson wrote:
[...]

The standard *could* have nailed this down more precisely. For
example, it could have said something like this:

... Whether the last line requires a terminating new-line
character is implementation-defined. If it does, closing the file
writes a new-line to the stream if the last character written to
the stream was not a new-line.

This would allow a text file with no terminating new-line to be
created on systems that don't require it, while guaranteeing (barring
errors) a properly terminated file on systems that do require it.

[...]

What if the terminating-newline-requirement was device dependent? What
if the "terminal" where the stream ends up works just fine without the
terminating newline, but the "printer" attched to some other output
stream requires it in order to print the line? How is the C library to
know whether the output device needs it or not?

The C library, or whatever lower-level code it invokes, obviously has
to know how to write to whatever device it's talking to. Knowing
whether that device requires a trailing new-line shouldn't be a
significant addtional burden.

If that's not possible for some reason, I suppose the standard could
allow fclose() to write an extra new-line even if it's not strictly
required.