RE: unbuffered fread() deadlock

["Schwarz, Konrad" <konrad dot schwarz at siemens dot com>]

> -----Original Message-----
> From: newlib-owner@sourceware.org 
> [mailto:newlib-owner@sourceware.org] On Behalf Of Jeff Johnston
> Subject: Re: unbuffered fread() deadlock
> 
>   Now, that said.  Why is it there?  From my old IBM C/370 
> library days 
> I seem to remember this
> was meant for terminal I/O.  Consider the following test case:
> 
> #include <stdio.h>
> #include <string.h>
> 
> int main() {
>     int a;
>     printf("a is ");
>     scanf("%d", &a);
>     printf("b is ");
>     fprintf(stderr, "c is 5\n");
>     return 0;
> }
> 
> This test when run under newlib and glibc runs as follows 
> (where I enter 
> the number 3)
> 
> a is 3
> c is 5
> b is <prompt>
> 
> Note how the stdout buffer gets flushed before the input for a is 

Ah!  But this is more than the standard requires.

I clearly remember this sort of style failing on Ultrix (which ran on
the class of machine that newlib might run on today).  To ensure that
line-buffered output appeared on the terminal, either you had to
terminate the output with a newline, or you had to call fflush() -- this
is the point of fflush().

This behavior was surprising to people with an MS-DOS background (who
wanted to write dialog style programs instead of the Unix software
tools/pipes and filters approach), which may have been the reason for
changing it.

However, the Unix way is designed for maximum throughput.  This
performance advantage is lost with newlib's current behavior and cannot
be recaptured.  On the other hand, portable programs are required to
call fflush() if they require output to be produced.

Regards,

Konrad Schwarz