X-Recipient: archive-cygwin@delorie.com
X-Spam-Check-By: sourceware.org
Date: Fri, 23 Oct 2009 12:12:41 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Python throws error when closing /dev/urandom
Message-ID: <20091023101241.GA5369@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <loom.20091022T210419-725@post.gmane.org> <416096c60910221255i550948a1n10301cd417e9f5cd@mail.gmail.com> <416096c60910221311n5f3d5f4m673dacebdc89833e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <416096c60910221311n5f3d5f4m673dacebdc89833e@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie.com@cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com

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

