Message-Id: <5.0.1.4.0.20001201234954.0347fec0@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 00:30:41 -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: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>, djgpp-workers AT delorie DOT com
In-Reply-To: <4331-Fri01Dec2000184658+0200-eliz@is.elta.co.il>
References: <200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se>
 <200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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
Precedence: bulk

At 06:46 PM 12/1/00 +0200, Eli Zaretskii wrote:
 >> From: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
 >> Date: Fri, 1 Dec 2000 15:35:13 +0100 (MET)
 >>
 >>      F_GETLK64      Equivalent to F_GETLK,  but  takes  a  struct
 >>                     flock64  argument  rather than a struct flock
 >>                     argument.
 >
 >Thanks, Martin!
 >
 >Peter, I think this explains everything.  If you don't mind writing
 >yet another bunch of "case F_..." clauses and adding the necessary
 >code to support FAT32, it would be mighty nice ;-).

I went to the url that Mark pointed to, and I see the "transitional" 
rules that allow this type of enhancement.  It seems easy enough to add 
the #define that says we handle 64-bit file offsets, and the bits that 
apply to fcntl() 64-bit functionality depending on that #define, but 
there are a *whole* lot of *other* 64-bit I/O functions involved in 
setting up a complete 64-bit file environment.  I'm *not* sanguine 
about being able to get all of those written and installed correctly, 
and I'm of the opinion that 64-bit file locking is really useless 
without 64-bit file *access*.  I would submit that 64-bitness for DJGPP 
is an entirely new project, separate from enabling locking in fcntl(), 
and quite frankly better handled by someone with more intimate (and to 
the point, more practical) internals knowledge than I possess at this 
time.

I'm also not real clear on how the _dos_lock and _dos_unlock functions 
would have to be modified to pass 64-bit values to int21/5c.  From RBIL 
61, the parameters to int21/5c are:

AH = 5Ch
AL = subfunction
     00h lock region of file
     01h unlock region of file
BX = file handle
CX:DX = start offset of region within file
SI:DI = length of region in bytes

Now, unless all of CX, DX, SI, and DI are DWORD's, that's only 32 bits 
each for the offset and the length.  Am I not seeing something?  And 
the code in _dos_lock (and unlock) also implies only 32 bits each:

r.x.cx = _offset >> 16;
r.x.dx = _offset;
r.x.si = _length >> 16;
r.x.di = _length;

Where do we provide the other 32 bits for each parameter to INT21?

I will proceed with the F_RDLCK -> F->WRLCK translation, along with the 
documentation updates already discussed, but I'd like a whole lot more 
detailed guidance before I can agree to 64-bitness enhancements.

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