Message-Id: <5.0.2.1.0.20010101123551.0337e9b0@pop5.banet.net>
X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Mon, 01 Jan 2001 13:01:28 -0500
To: djgpp-workers AT delorie DOT com
From: "Peter J. Farley III" <pjfarley AT banet DOT net>
Subject: Re: fcntl locking changes #3: Notes
In-Reply-To: <3A50796D.CB476531@phekda.freeserve.co.uk>
References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001231145420 DOT 00a8bab0 AT pop5 DOT banet DOT net>
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 12:34 PM 1/1/01 +0000, Richard Dawe wrote:
 >Hello.
 >
 >"Peter J. Farley III" wrote:
 >> There are "*.ok" files in each of the test directories for fcntl,
 >> flock, and [l]lockf.  These show the results I got on my W98SE/DOS
 >> box/LFN=y system.  YMMV.
 >
 >I applied the dostrerror(), fcntl() and flock() + *lockf() patches.
 >I get the same results as you, but the output has file descriptor 7
 >rather than 5. (Please note that I did my tests on a copy of
 >unmodified sources from CVS, with Peter's patches.) I tested in the
 >same conditions as you, Peter.

You ran them from inside bash.  I ran under COMMAND.COM to get the *.ok 
files.  When I run them under bash I get the same results as you, fd = 
7.  I think bash has more open file descriptors while running, so I 
think that explains the difference.

 >Tests I ran:
 >
 >tests/libc/posix/fcntl/fcntl3gb.exe
 >tests/libc/posix/fcntl/tfcntl.exe
 >tests/libc/posix/fcntl/tfcntl2.exe
 >tests/libc/compat/unistd/tllockf.exe
 >tests/libc/compat/unistd/tlockf.exe
 >tests/libc/posix/sys/file/tflock.exe
 >
 >If I've missed any, please tell me and I'll run them.

Nope, you got them all in that version of the patches.  Thanks for the 
testing and report.  Please also try version #3a of the main patch, 
posted yesterday, Dec. 31.  There is one additional test, Mark E.'s 
inherit.c, which under COMMAND.COM reports fd's 5 and 6, and under bash 
should report fd's 7 and 8 (I just tested that to confirm).

 >> ljmp/lcall patch        Required before building anything with gcc
 >2.952
 >>                         Includes changes to src/makefile.inc for 
GAS
 >>                         versions and LIBGCCA
 >
 >Why is this required? gas seems to produce the same code for lcall.
 >Does it not do the right thing for ljmp? I can retest with the patch, 

 >if you'd like.

Under gcc 2.952 on my system (as.exe version 2.9.5 from bnu2951b.zip), 
gas complains that the ljmp/lcall operands are (are not? I forget now 
which way it went) indirect.  Adding a "*" operator in front of the 
operands quiets the message.  Eli advised they should be fixed, even 
though they do not stop the make, nor did it seem (in the early days of 
my testing, not tested without that patch since then) to affect the 
running of libc functions and tests.

I truly do not know if they are "required" or not, but it seemed like 
the Right Thing to do to eliminate the warnings.

Thanks again for your help.

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