Bug or correct behavior?

Bug or correct behavior?

[finkler]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

Hi there,

I attached a little program which reads from a freopen'd stdin in an 
infinite loop.
With glibc I can then monitor the opened file, meaning if I write to it 
from another process, my never-dying program can read and print it.
With musl nothing happens.
Is this some glibc quirk or is it a bug in musl?

Btw. I am using musl 0.8.6

regards,
finkler

[-- Attachment #2: test.c --]
[-- Type: text/plain, Size: 442 bytes --]

#include <stdlib.h>
#include <stdio.h>

int
main(int argc, char *argv[]) {
  int c;
  
  if(!freopen(argv[1], "r", stdin)) {
    printf("can't open %s", argv[1]);
    exit(1);
  }
  for(;;) {
    sleep(3);
    while((c = fgetc(stdin)) != EOF) {
      if(fputc(c, stdout) == EOF) {
        printf("error write");
        exit(1);
      }
    }
    if(ferror(stdin)) {
      printf("error read");
      exit(1);
    }
    fflush(stdout);
  }
}

Re: Bug or correct behavior?

[Rich Felker]

On Sat, Mar 17, 2012 at 05:24:26PM +0100, finkler wrote:
> Hi there,
> 
> I attached a little program which reads from a freopen'd stdin in an
> infinite loop.
> With glibc I can then monitor the opened file, meaning if I write to
> it from another process, my never-dying program can read and print
> it.
> With musl nothing happens.
> Is this some glibc quirk or is it a bug in musl?

Your code depends on glibc bug number 1190:
http://sourceware.org/bugzilla/show_bug.cgi?id=1190

POSIX requires the EOF status of stdio streams to be sticky, i.e. the
EOF flag for a stream is set when it reaches EOF, and all subsequent
reads have to check that EOF flag and fail if it's set. To clear the
EOF flag you can use clearerr or rewind/fseek.

glibc ignores this part of the standard and ignores the EOF flag when
attempting to read.

To fix your code, simply call clearerr(stdin) after hitting EOF.

Rich