Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id:	<200004022129.QAA11391@hp2.xraylith.wisc.edu>
To:	"J. David Bryan" <dbryan AT bcpl DOT net>
cc:	Cygnus Win32 List <cygwin AT sourceware DOT cygnus DOT com>
Subject:	Re: Permission denied with makeinfo from texinfo-4.0
In-reply-to:	Your message of "Sun, 02 Apr 2000 17:22:08 EDT."
	<200004022122 DOT RAA03881 AT mail DOT bcpl DOT net>
Date:	Sun, 02 Apr 2000 16:29:06 -0500
From:	Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>

"J. David Bryan" <dbryan AT bcpl DOT net> writes:
> 
> I observed the problem with makeinfo with a read of a little over 10K.  A 
> 32K buffer size may always fail, but it's not necessary to cause failure.
> 
> I confess that I haven't tried to trace the actual ReadFile code, but it 
> appears to check the accessibility of the entire buffer using the length 
> specified in the call before actually determining the number of bytes left 
> to read.  If the buffer accessibility check fails, ERROR_NOACCESS is 
> returned.

Thanks for the followup and clarification. I only tested a set of simple
cases, and didn't check for the crossing page boundary issue.

> The particular case in makeinfo is that after reading a full buffer's worth 
> of file data, it tries to read a *second* full buffer's worth of data with 
> the buffer pointer pointing at the *end* of the original buffer (i.e., to 
> unallocated space).  ReadFile checks the validity of this area, and if the 
> unallocated space crosses a page boundary into a protected page, the 
> ERROR_NOACCESS fault occurs.

Argh. I'll redo my testcase and try to understand this issue.

> I checked this by tracing the makeinfo code with gdb, and if I altered the 
> second call on the fly to specify a size that kept the unallocated space 
> wholly within the page containing the original buffer, ReadFile correctly 
> returned 0.  If I increased the call length by one, such that the 
> unallocated buffer space extended into the next page by a single byte, 
> ERROR_NOACCESS was returned.
> 
> One can argue whether specifying an invalid buffer to ReadFile should or 
> should not fail if there are no more bytes left to read.  Either way, there 
> is clearly a bug in makeinfo -- if the file is extended between the stat 
> call that is used to allocate the buffer, and the read call that fills it, 
> the routine will scribble on unallocated space.

I agree that this is indeed a bug in makeinfo (I'm looking at it right
now); as for whether ReadFile should fail or not, I'm for the least 
surprise principle where it should simply say 0 and not didle with 
checking the buffer correctness if at the end of file -- sort of a 
short-circuit approach.

Thanks for sharing your insight into this issue. I suppose I should in
all fairness go back and read the whole thread now ... 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -