Date:	Sat, 02 Dec 2000 18:54:21 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	pjfarley AT banet DOT net
Message-Id:	<4331-Sat02Dec2000185420+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC:	eplmst AT lu DOT erisoft DOT se, djgpp-workers AT delorie DOT com
In-reply-to:	<5.0.1.4.0.20001202095034.0259fd60@pop5.banet.net>
	(pjfarley AT banet DOT net)
Subject:	Re: Locking fcntl() and flock() patches
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> <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001202095034 DOT 0259fd60 AT pop5 DOT banet DOT net>
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

> Date: Sat, 02 Dec 2000 10:00:44 -0500
> From: "Peter J. Farley III" <pjfarley AT banet DOT net>
> 
> 1.	How do I get copies of this FAT32 support code, since the copy of 
> djlsr203.zip that I have does not contain it?

Via the anon CVS, I suppose.

If you have difficulties with that, I could send you the affected
files if Martin tells me what they are.

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

It's offset_t, I think.

>  >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?

I thought we should use F_RDLCK64 regardless, for compatibility with
other systems; I doubt if F_RDLCK32 will ever be used by some
platform.

> You seem to be saying we add 64-bit types, and only use the
> low-order 32 bits.

Something like that, yes.  I thought about some minimal compatibility,
on the source level, to systems which support true 64-bit file
offsets.

- Raw text -