Message-Id:	<5.0.1.4.0.20001202095034.0259fd60@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 5.0.1
Date:	Sat, 02 Dec 2000 10:00:44 -0500
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: Locking fcntl() and flock() patches
Cc:	eplmst AT lu DOT erisoft DOT se, djgpp-workers AT delorie DOT com
In-Reply-To:	<1438-Sat02Dec2000104925+0200-eliz@is.elta.co.il>
References:	<5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001201234954 DOT 0347fec0 AT pop5 DOT banet DOT net>
	<200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se>
	<200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se>
	<5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001201234954 DOT 0347fec0 AT pop5 DOT banet DOT net>
Mime-Version:	1.0
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

At 10:49 AM 12/2/00 +0200, Eli Zaretskii wrote:
<Snipped>
 >Sorry, this is a misunderstanding.  I didn't mean to imply that you
 >should write 64-bit file support for DJGPP as part of improving 
fcntl.
 >What I meant is that it would be nice to include FAT32 support that 
is
 >_already_ part of the CVS sources for `_open', `_read', and `llseek'
 >(added by Martin).  FAT32 allows support of up to 4GB 
file-size.  This
 >is stil 32-bit, but it uses the entire 32-bit width of the registers.

Ah!  My thick headedness, apologies.  So, now I have two questions:

1.	How do I get copies of this FAT32 support code, since the copy of 
djlsr203.zip that I have does not contain it?

2.	What is the new type that we use to get "unsigned long" for off_t 
variables and parameters?

 >The issue of supporting FAT32 in fcntl boils down to adding a few 
more
 >case blocks which accept F_RDLCK64 etc. commands and manipulate the
 >64-bit equivalent of struct flock, but otherwise do the same.

Excuse me, didn't you just say we're supporting FAT32?  Shouldn't the 
types we're introducing be, e.g. F_RDLCK32?

<Snipped>
 >FAT32 still uses 32-bit values, but they are unsigned.
 >
 >The question whether 215C supports FAT32 is an open one: I asked that
 >here as part of this discussion; hopefully, someone could try that 
and
 >provide an answer.
 >
 >I agree that if 215C doesn't support FAT32, this is a moot point, and
 >we should simply document that fact and continue.

Well, I can see my way to providing unsigned 32-bit versions, assuming 
the appropriate types are already defined, but I am still confused by 
your use of the "64" suffix.  You seem to be saying we add 64-bit 
types, and only use the low-order 32 bits.  Did I interpret that 
correctly?  Or am I just confused because I have not yet seen the new 
headers?

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -