Mail Archives: djgpp-workers/2000/12/13/06:22:43
On Tue, 12 Dec 2000, Peter J. Farley III wrote:
> >> All coded tests just use zero offsets.
> >
> >Isn't it better to try non-zero offsets as well? You could get them
> >from `rand', for example.
> >
> >That would also allow an easy test on FAT32 systems, if you probe for
> >FAT32 support and provide a special test for that, which actually
> >tries to lock after 2GB.
>
> Except we really need to create (say) a 3GB file to test that the code
> correctly performs the function, don't we? And I don't have 3GB disk
> space to spare at the moment.
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.
> 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.
> 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.
> 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.
> >> +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?
> >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.
> >> + /* If l_len is zero, then the lock is to be set from l_start
> >> + until the end-of-file. */
> >> + if (len == 0)
> >> + {
> >> + len = filelength(fd) - cur_pos;
> >> + /* This should probably be an error. */
> >> + if (len <= 0)
> >> + len = 1;
> >> + }
> >
> >Perhaps the case where filelength returns a negative value (can it?)
> >should indeed return an error, but if filelength returns zero
> (meaning
> >the file is empty), it should succeed, I think, because fcntl allows
> >to lock regions beyond the current EOF. The question is: does
> >DOS/Windows allow that? Otherwise, it is not clear to me why the
> >above snippet bumps len to 1.
>
> Because that's the way Mark originally coded it. I didn't change it at
> all from his version.
Mark, can you please tell why was this written like that?
> 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").
> >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.
- Raw text -