Message-Id: <5.0.2.1.0.20010102000434.0274c0c0@pop5.banet.net>
X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 02 Jan 2001 00:19:05 -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
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <3A50FBF8.4A88145B@phekda.freeserve.co.uk>
References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001231145420 DOT 00a8bab0 AT pop5 DOT banet DOT net>
 <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20010101123551 DOT 0337e9b0 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 09:51 PM 1/1/01 +0000, Richard Dawe wrote:
 >Hello.
<Snipped>
 >Yes, I used bash.

I'm glad that explains it.

 >> 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.
 >
 >I did apply version #3a, but I missed the inherit test. I get the 
same
 >results as you - again, under bash, with higher file descriptors in 
the
 >results.

Terrific, thank you for your help and reporting.

 >> 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.
 >
 >While trying to fix similar warnings in libsocket, I found that the
 >code
 >generated for lcall was the same with or without the '*'. I did not
 >compare code generation for ljmp. I have to say that the current
 >solution
 >for DJGPP are more elegant than the one I used in libsocket, libwin.

I did not think to look at the code generation, I was only dealing with 
the warning errors.  Curious that it generates the same object code, 
but as long as it works, I'm happy.  And I'm glad my solution seems 
elegant, but I have to give credit where credit is due -- the idea for 
the macros for LCALL/LJMP was due to Morten Welinder, and the idea to 
use "suitable GNU Make magic, using the built-in string-manipulation 
functions" is due to Eli.

Thanks again for your help.

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