Mail Archives: djgpp-workers/2000/12/13/20:47:04
At 01:19 PM 12/13/00 +0200, Eli Zaretskii wrote:
>On Tue, 12 Dec 2000, Peter J. Farley III wrote:
<Snipped>
>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.
<l_len == 0 stuff snipped>
>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)
- Raw text -