Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Sat, 14 Dec 2002 13:03:14 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Changed fhandler_* read and raw_read methods throughout
Message-ID: <20021214180314.GA11428@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20021214040532 DOT GA3368 AT redhat DOT com> <20021214175544 DOT N19104 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021214175544.N19104@cygbert.vinschen.de>
User-Agent: Mutt/1.5.1i

On Sat, Dec 14, 2002 at 05:55:44PM +0100, Corinna Vinschen wrote:
>Hi Chris,
>
>On Fri, Dec 13, 2002 at 11:05:32PM -0500, Chris Faylor wrote:
>> To accommodate my recent pipe changes, I've changed all of the
>> fhandler_* read and raw_read methods.  I've changed them to void
>> functions whose second parameter is both the length and the return
>> value.
>> 
>> I've done this so that if the ReadFile in raw_read succeeds but a signal
>> happens shortly thereafter, the number of bytes read will be available
>> to the caller even though the thread which did the read has been
>> terminated.
>> 
>> It's possible that I got one of the many fhandler functions wrong when I
>> went through making this change so if you see odd behavior this is the
>> place to check.
>
>your changes disable tcsh's ability to read script files correctly. 
>
>AFAICS, you overoptimized the part looking for CRLF in
>fhandler_base::read() by not writing the last character if it happens
>not to be a \r.  This can only be observed when reading in O_TEXT mode.

I can see why this would happen but I wonder how I missed this when I
tested it.  Must have been tired.

>Another point is the "else if (copied_chars <= 0)" stuff after the first
>raw_read call.  As I understand that part, it actually should return
>here if raw_read returned 0 or -1 and copied_chars is 0 as well.  Your
>changes in the lines above don't copy the correct count of bytes read
>back into copied_chars as the original code did so at this point, it
>should now ask for the value of 'len' shouldn't it?  I attached a patch
>for review.

Thanks for the patch.  I ended up reorganizing this function YA so that
it exits from the bottom.  There is also a possibility of dereferencing
a pointer beyond the end of the passed in buffer, which still needed to
be handled, AFAICT.

I've checked in a new patch.  Does tcsh work now?

Btw, there are still some problems with the pipe reader that I'm working
on.  It is possible to get cygwin to block indefinitely on a pipe read
when a pipe is opened in text mode.

I sure do love text mode.  And Windows 95.

Thanks for alerting me to this problem.

cgf