X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 23 Oct 2009 12:12:41 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Python throws error when closing /dev/urandom
Message-ID: <20091023101241.GA5369@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20091022T210419-725 AT post DOT gmane DOT org> <416096c60910221255i550948a1n10301cd417e9f5cd AT mail DOT gmail DOT com> <416096c60910221311n5f3d5f4m673dacebdc89833e AT mail DOT gmail DOT 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 AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT 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