Message-Id: <5.0.2.1.0.20001213202344.00a512f0@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 13 Dec 2000 20:47:58 -0500 To: Eli Zaretskii From: "Peter J. Farley III" Subject: Re: Locking fcntl changes #2 Cc: djgpp-workers AT delorie DOT com In-Reply-To: References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001212203315 DOT 025a6ab0 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 01:19 PM 12/13/00 +0200, Eli Zaretskii wrote: >On Tue, 12 Dec 2000, Peter J. Farley III wrote: >If you write the code to create such a file, then someone (perhaps >even myself) with access to a sufficiently large FAT32 volume will not >need to work so hard to test it. The main point of having a test >suite is that it makes testing easier, because the testers doesn't >have to concern themselves with thinking about what to do to prepare >the test. OK, I can cobble something together, I think. >> Dividing the file length by 4 and locking/unlocking each quarter of >> the file opened should be enough of a test, right? > >I was not proposing any exhaustive testing; I don't expect anyone of >us to have enough resources for that. But having a test which doesn't >set the offset to a non-zero value even once is certainly not good, >because a non-zero offset might hit some code which the zero offset >case never exercises. > >So I think even if you test only one zero and one random non-zero >offset, it will be good enough. OK, I can try to do that. >> I have no problem just using "errclass_str", "erraction_str" and >> "errlocus_str", if that's what seems to work better. > >I think it's better. OK, done. >> I'll go with the majority usage, assuming we can find it out. FWIW, >> the man page on Debian/GNU systems says it returns "EACCES or EAGAIN" >> and doesn't tell you which is given under what circumstances. > >EACCES is too ubiquitous on DOS, so I'd prefer EAGAIN. I must respectfully disagree. Isn't EACCES a much better description of a locking error than EAGAIN? EACCES may be too common, but aren't locking violations exactly what EACCES was intended to describe? Obviously it is easy to change EACCES to EAGAIN, it's just that EACCES says more to *me* than EAGAIN, if I'm programming locking code. That's just IMHO, of course. I will defer to the opinion of the majority (or to you, Eli) if there is strong sentiment that EACCES is not appropriate. >> >> +The @code{llockf} utility will fail >> > >> >llockf is not a utility. >> >> OK. Use "command" instead, right? > >I'd say "function", actually. You _are_ talking about a function, >right? Right. Done. >> >Should all those "Reserved" be replaced by "Unknow error: XX"? >> >> I'm *not* going to manually code all those items as unknown. But I >> *can* easily code the function to replace "Reserved" with the >> "Unknown" message. Will that do? > >Yes. Done. >Mark, can you please tell why was this written like that? After further research, I don't think we need Mark to reply on this. I think the use of "cur_pos" is an error here. I believe that should have been "lock_pos", not "cur_pos". The definition of the function says "from l_start to the end of the file", and "lock_pos" is what holds the effective value of "l_start+l_whence", not "cur_pos". The modified calculation can still be negative, but that is allowable for the case where "l_start+l_whence" has been specified as a position beyond the end of the file. In that case, the region to be locked is from the end of the file to "l_start", and the code below this point will handle that case (with another small correction). The zero case *after* the calculation is still the question-mark. I have some preliminary tests done which indicate that a zero length is, in fact, allowed by the int21/5C code. When I have confirmed this, we can remove the test that Mark coded entirely, and let the length be computed to whatever the programmer intended. IOW, no error is needed here, assuming int21/5C accepts a zero length. >> Could I replace all of the erroneous @ref{}'s I have used without >> commas or periods with @pxref{}'s to avoid that problem? > >No :-(. @pxref produces output that is inappropriate except inside >parentheses (thus the `p' in "pxref"). OK. >> >Last, but not least: thanks for all the work! >> >> Labors of love are a *lot* more work than they ever appear at the >> start... :) > >It always is ;-). > >Note that it is up to you to decide which of the suggestions you >choose not to implement due to lack of resources. No one can force >you to do something which you don't have time for. Understood. I will do what I can. --------------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org OR pjfarley AT banet DOT net)