newbie EOF question

[CBFalconer]

printf("prompt");
getchar();

Data will be retrieved from stdin (assuming any is available).
Dan made no remarks about the output from 'printf()'.

Oh. Apologies for my slowness.

 

[Dan Pop]

Chapter and verse time please.

The genuine guru I was mentioning above is actually Chris Torek.

- The input and output dynamics of interactive devices shall
take place as specified in 7.19.3. The intent of these
requirements is that unbuffered or line-buffered output appear
as soon as possible, to ensure that prompting messages actually
appear prior to a program waiting for input.
....
When a stream
is line buffered, characters are intended to be transmitted to or
from the host environment as a block when a new-line character
is encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer
is filled, when input is requested on an unbuffered stream, or
when input is requested on a line buffered stream that requires
the transmission of characters from the host environment.

Dan

 

[Jeremy Yallop]

Chapter and verse time please.

7.19.3

3 [...] When a stream is fully buffered, characters are intended to
be transmitted to or from the host environment as a block when a
buffer is filled. When a stream is line buffered, characters are
intended to be transmitted to or from the host environment as a
block when a new-line character is encountered. Furthermore,
characters are intended to be transmitted as a block to the host
environment when a buffer is filled, when input is requested on
an unbuffered stream, or when input is requested on a line
buffered stream that requires the transmission of characters from
the host environment.

The important part is: "When a stream is line buffered [...]
characters are intended to be transmitted as a block to the host
environment [...] when input is requested on a line buffered stream
that requires the transmission of characters from the host
environment."

Jeremy.

 

[Irrwahn Grausewitz]

The genuine guru I was mentioning above is actually Chris Torek.

- The input and output dynamics of interactive devices shall
take place as specified in 7.19.3. The intent of these
requirements is that unbuffered or line-buffered output appear
as soon as possible, to ensure that prompting messages actually
appear prior to a program waiting for input.
...
When a stream
is line buffered, characters are intended to be transmitted to or
from the host environment as a block when a new-line character
is encountered. Furthermore, characters are intended to be
transmitted as a block to the host environment when a buffer
is filled, when input is requested on an unbuffered stream, or
when input is requested on a line buffered stream that requires
the transmission of characters from the host environment.

Just to make sure I get it right: does this mean that the following
program is *guaranteed* to print the prompt before requesting input
(presuming no unexpected I/O errors occur)?

#include <stdio.h>

int main( void )
{
int c;
printf( "Enter a character: " );
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

TIA, Regards

 

[Jeremy Yallop]

Just to make sure I get it right: does this mean that the following
program is *guaranteed* to print the prompt before requesting input
(presuming no unexpected I/O errors occur)?

Not by the C standard. The next sentence begins "Support for these
characteristics is implementation-defined".

#include <stdio.h>

int main( void )
{
int c;
printf( "Enter a character: " );
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

Jeremy.

 

[Dan Pop]

Just to make sure I get it right: does this mean that the following
program is *guaranteed* to print the prompt before requesting input
(presuming no unexpected I/O errors occur)?

#include <stdio.h>

int main( void )
{
int c;
printf( "Enter a character: " );
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

No *guarantee* at all, but this is the intent of the standard.

For one thing, the implementation is free to decide that your
terminal/console/whatever is not an interactive device. You could
improve your chances, by forcing line buffering on stdout and no
buffering on stdin, though, but the implementation is free to reject
your attempts at doing that...

Dan

 

[Irrwahn Grausewitz]

[output buffer flushed when input is requested, C99 7.19.3#3 ]

Not by the C standard. The next sentence begins "Support for these
characteristics is implementation-defined".

Ack. I should've looked it up before posting...

I will stick to inserting
fflush( stdout );
here.

Thanks & Regards

 

[Dan Pop]

[output buffer flushed when input is requested, C99 7.19.3#3 ]

Not by the C standard. The next sentence begins "Support for these
characteristics is implementation-defined".

Ack. I should've looked it up before posting...

I will stick to inserting
fflush( stdout );
here.

If the implementation is perverse enough, it wouldn't help. Any
reasonable implementation would follow the intent of the standard and
the fflush call is useless.

Dan

 

[Irrwahn Grausewitz]

[output buffer flushed when input is requested, C99 7.19.3#3]

No *guarantee* at all, but this is the intent of the standard.

For one thing, the implementation is free to decide that your
terminal/console/whatever is not an interactive device. You could
improve your chances, by forcing line buffering on stdout and no
buffering on stdin, though, but the implementation is free to reject
your attempts at doing that...

Thanks for clarification.

Regards

 

[Ed Morton]

Irrwahn Grausewitz wrote:

(e-mail address removed) (Dan Pop) wrote:

[output buffer flushed when input is requested, C99 7.19.3#3 ]

Just to make sure I get it right: does this mean that the following
program is *guaranteed* to print the prompt before requesting input
(presuming no unexpected I/O errors occur)?

Not by the C standard. The next sentence begins "Support for these
characteristics is implementation-defined".

Ack. I should've looked it up before posting...

#include <stdio.h>

int main( void )
{
int c;
printf( "Enter a character: " );

I will stick to inserting
fflush( stdout );
here.

If the implementation is perverse enough, it wouldn't help. Any
reasonable implementation would follow the intent of the standard and
the fflush call is useless.

I agree it's useless in the above code, but if we introduce a bug that produces
a segmentation fault:

#include <stdio.h>

int main( void )
{
int *p = NULL;
int c;
printf( "Enter a character: " );
*p = 1;
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

then an fflush() after the first printf() will ease debugging. The above will
produce no output so the user won't know where to start looking for the problem,
whereas this:

#include <stdio.h>

int main( void )
{
int *p = NULL;
int c;
printf( "Enter a character: " );
fflush(stdout);
*p = 1;
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

will produce the "Enter a character" prompt so the user will know to start
looking for the bug after that point.

Ed.

 

[Chris Torek]

The genuine guru I was mentioning above is actually Chris Torek.

[C standard reference to behavior of input from non-fully-buffered
streams snipped -- the summary is that getc on stdin will *usually*
call fflush(stdout) for you.]

Of course, I also always point out that implementations are allowed
to be arbitrarily perverse in setting up standard-stream buffering.
Moreover, on typical Unix-like systems, running one interactive
program with its output piped into another program for any purpose
-- for instance, doing something like:

./interact | tee save_the_output

-- causes the interactive program to believe that its standard output
should be "fully buffered", so that the auto-fflush() does *not*
occur. Thus, I recommend the explicit fflush(stdout) anyway.

(These various additional facts are noted elsethread, but I want to
point out that I always try to mention them myself.)

 

[Irrwahn Grausewitz]

[about output buffer flushed when input is requested, C99 7.19.3#3 ]

If the implementation is perverse enough, it wouldn't help. Any
reasonable implementation would follow the intent of the standard and
the fflush call is useless.

Is it likely for one to run across a 'moderately perverse'
implementation where fflush would actually help?

Regards

 

[Dan Pop]

Irrwahn Grausewitz wrote:

(e-mail address removed) (Dan Pop) wrote:

[output buffer flushed when input is requested, C99 7.19.3#3 ]


Just to make sure I get it right: does this mean that the following
program is *guaranteed* to print the prompt before requesting input
(presuming no unexpected I/O errors occur)?

Not by the C standard. The next sentence begins "Support for these
characteristics is implementation-defined".

Ack. I should've looked it up before posting...


#include <stdio.h>

int main( void )
{
int c;
printf( "Enter a character: " );

I will stick to inserting
fflush( stdout );
here.

If the implementation is perverse enough, it wouldn't help. Any
reasonable implementation would follow the intent of the standard and
the fflush call is useless.

I agree it's useless in the above code, but if we introduce a bug that produces
a segmentation fault:

#include <stdio.h>

int main( void )
{
int *p = NULL;
int c;
printf( "Enter a character: " );
*p = 1;
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

then an fflush() after the first printf() will ease debugging. The above will
produce no output so the user won't know where to start looking for the problem,
whereas this:

#include <stdio.h>

int main( void )
{
int *p = NULL;
int c;
printf( "Enter a character: " );
fflush(stdout);
*p = 1;
c = getchar();
printf( "You entered: %c\n", c );
return 0;
}

will produce the "Enter a character" prompt so the user will know to start
looking for the bug after that point.

The smart programmer wouldn't bother: any decent debugger can point out
the exact place where the program crashed.

I'm a big fan of printf debugging, but there is no point in wasting time
with printfs when the debugger can immediately point you to the right
place.

Dan

 

[CBFalconer]

Chapter and verse time please.

7.19.3

3 [...] When a stream is fully buffered, characters are intended to
be transmitted to or from the host environment as a block when a
buffer is filled. When a stream is line buffered, characters are
intended to be transmitted to or from the host environment as a
block when a new-line character is encountered. Furthermore,
characters are intended to be transmitted as a block to the host
environment when a buffer is filled, when input is requested on
an unbuffered stream, or when input is requested on a line
buffered stream that requires the transmission of characters from
the host environment.

The important part is: "When a stream is line buffered [...]
characters are intended to be transmitted as a block to the host
environment [...] when input is requested on a line buffered stream
that requires the transmission of characters from the host
environment."

The operative word there is "intended". Such action is not
required, thus the fflush action is required to /ensure/ the
output precedes the input, for some value of ensure. I am sure
you can come up with many scenarios in which ensuring such action
would be a serious handicap.

 

[those who know me have no need of my name]

in comp.lang.c i read:

Is it likely for one to run across a 'moderately perverse'
implementation where fflush would actually help?

there are sufficiently perverse uses of programs such that it can help,
yes. e.g., where stdout is connected to a non-interactive thing which
never the less copies the output to an/the interactive device -- i.e.,
chris torek's recent response re use of a program with a pipe.

the only real reason not to call fflush(stdout) is performance, and you
aren't likely to be shooting for lots of performance with most sorts of
stuff sent to stdout which is intended to provoke data to arrive via stdin.
(as with most things -- this has any number of fairly obvious exceptions.)

 

[Irrwahn Grausewitz]

in comp.lang.c i read:


there are sufficiently perverse uses of programs such that it can help,
yes. e.g., where stdout is connected to a non-interactive thing which
never the less copies the output to an/the interactive device -- i.e.,
chris torek's recent response re use of a program with a pipe.

Yes, I read it a minute ago.

the only real reason not to call fflush(stdout) is performance, and you
aren't likely to be shooting for lots of performance with most sorts of
stuff sent to stdout which is intended to provoke data to arrive via stdin.
(as with most things -- this has any number of fairly obvious exceptions.)

I was indeed not concerned about performance...

Thanks & Regards

 

[Dan Pop]

[about output buffer flushed when input is requested, C99 7.19.3#3 ]

If the implementation is perverse enough, it wouldn't help. Any
reasonable implementation would follow the intent of the standard and
the fflush call is useless.

Is it likely for one to run across a 'moderately perverse'
implementation where fflush would actually help?

Never seen one. However, I recommend displaying all the user prompts
to stderr, because they're really not part of the program's output.
If stdout is redirected to a file, with or without fflush, the user
won't see them at all. Redirecting stderr is far less common in programs
that are started interactively.

stderr doesn't need fflush any more than stdout, in this case.

Dan