On Oct 22 21:11, Andy Koppe wrote:
> > Reproduced the issue with this C test:
> >
> > #include <stdlib.h>
> > #include <stdio.h>
> >
> > int main(void) {
> > FILE *f = fopen("/dev/urandom", "r");
> > if (!f) {
> > puts("fopen failed");
> > return 1;
> > }
> > char buf[8];
> > printf("read %i bytes\n", fread(buf, 1, sizeof buf, f));
> > if (fclose(f)) {
> > puts("fclose failed");
> > return 1;
> > }
> > return 0;
> > }
> >
> > The fclose fails on Cygwin, but succeeds on Debian.
>
> ps: Same issue with /dev/zero, /dev/full, and also /dev/clipboard.
I fixed this issue for /dev/[u]random in CVS, which didn't behave
as Linux.
I can reproduce it for the other devices. However, they all (well,
/dev/zero and /dev/full) behave like their Linux counterpart. It seems
this is a bug in newlib's fflush, or rather, _fflush_r. It expects
that the lseek call returns the exact correct, expected position after
a relative seek. If lseek returns some other value, 0 for instance,
it treats that as an error. Actually it should only treat an actual
error return as error, afaics.
I'll follow up on the newlib list.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
