Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Sun, 2 Apr 2000 20:46:34 -0400
From: Christopher Faylor <cgf AT cygnus DOT com>
To: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
Cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Permission denied with makeinfo from texinfo-4.0
Message-ID: <20000402204634.D23469@cygnus.com>
Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com
Mail-Followup-To: Christopher Faylor <cgf AT cygnus DOT com>,
	Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>,
	cygwin-developers AT sourceware DOT cygnus DOT com
References: <20000315085203 DOT D19524 AT cygnus DOT com> <Pine DOT HPP DOT 3 DOT 96 DOT 1000402155518 DOT 6174H-100000 AT hp2 DOT xraylith DOT wisc DOT edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <Pine.HPP.3.96.1000402155518.6174H-100000@hp2.xraylith.wisc.edu>; from khan@NanoTech.Wisc.EDU on Sun, Apr 02, 2000 at 03:58:57PM -0500

On Sun, Apr 02, 2000 at 03:58:57PM -0500, Mumit Khan wrote:
>On Wed, 15 Mar 2000, Chris Faylor wrote:
>> This sounds correct to me.  Passing what is essentially a bogus argument
>> for the buffer length is just wrong.  At the very least, it's subject to
>> problems if the file size changes while you're reading it.  Admittedly
>> this is an unusual occurrence but why not program for something like this
>> and fail gracefully rather than core dumping?
>> 
>
>fyi, the makeinfo bug is caused by a (undocumented of course) bug in Win32 
>ReadFile routine.
>
>Here's what David Korn says when it showed up in UWIN as well:
>
>Yet some more bizarre undocumented win32 behavior.  If you call the
>Win32 ReadFile() function with size greater than 32K, and you are at
>the end of file, it does not return successfully with 0 bytes as you
>would expect, but fails with ERROR_NOACCESS.
>
>This should be fixed in the runtime, but I have to find a reliable way
>to detect this (since we have to differentiate between this buggy
>behaviour and other legitimate causes of ERROR_NOACCESS).

Are we sure that this is a correct analysis?  The previous analysis was
that ReadFile was being passed a length which was larger than its
supplied buffer.  That is (to me) inarguably wrong.  You can't say "I
know how big the file is" because you can *never* know how big the file
is in a multi-tasking operating system.

It seems like Dave Bryan went to some effort to track this down and I don't
see that his analysis is incorrect.

cgf