X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
Date:	Mon, 11 Apr 2005 01:12:40 -0600
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Subject:	Re: DJGPP v2.04 Bugs - suggested patch
In-reply-to:	<01c53e48$Blat.v2.4$1e183ec0@zahav.net.il>
To:	djgpp-workers AT delorie DOT com
Message-id:	<pv1k515mkpvd9182b1gobbmff6ms5kp01e@4ax.com>
Organization:	Systematic Software
MIME-version:	1.0
X-Mailer:	Forte Agent 1.93/32.576 English (American)
References:	<10504092012 DOT AA16787 AT clio DOT rice DOT edu>
	<200504101156 DOT j3ABu1k5002657 AT speedy DOT ludd DOT ltu DOT se>
	<phmi511ulpki0eeno5dclv1avhqul7rrjb AT 4ax DOT com>
	<01c53e00$Blat.v2.4$eacdb8c0 AT zahav DOT net DOT il>
	<q6cj51tds6do8tdrohei0svjom2lri2167 AT 4ax DOT com>
	<01c53e48$Blat.v2.4$1e183ec0 AT zahav DOT net DOT il>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id j3B7HidP002712
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 11 Apr 2005 06:38:48 +0300, Eli Zaretskii <eliz AT gnu DOT org>
wrote:

>> Date: Sun, 10 Apr 2005 17:13:28 -0600
>> From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
>> 
>> >Isn't it easier to install a SIGINT signal handler, which will fflush
>> >the stream and exit?
>> 
>> The issue is the amount of data in the library buffer to be flushed to
>> the OS: once there's too much in the buffer, the write will not
>> complete and you'll get an error; so you have to reduce the write
>> granularity near the end
>
>Perhaps I misunderstood: I thought the issue was how to produce the
>max size file even though the last chunk somehow causes the program to
>hang in some seemingly endless loop, and Ctrl-C is needed to break
>that.

The program seems to be attempting to write past the limit, and the
library seems to be either not getting, properly handling, or
returning, the OS error. 

>In principle, there should be no reason to increase the granularity
>near the end: the last write will indeed get an error, but before it
>does, it will write as many bytes as the OS allows to the disk.  So
>what we should see is an error and a 4GB file, and that's it.

I would not /expect/ any OS to perform a partial write of a block that
exceeds its limits, as it doesn't really matter whether it returns the
failure on the first byte of the requested block or the first byte
that exceeds the limit, it's still an I/O error on that transfer, so
it might as well check first and complain on the first byte. 

>Therefore, I think we have some kind of bug here, which should be
>investigated.  The trick with a signal handler is just a means to ease
>that investigation.

The OS vendor probably prefers the term feature. 
I fail to see why an OS would allow a write, that it has already
rejected, to complete on fflush() or fclose(). 

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian DOT Inglis AT CSi DOT com 	(Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address		use address above to reply

- Raw text -