Mail Archives: djgpp-workers/2001/10/25/11:43:43
> I'd say lets change all the functions in this family to return EFAULT.
Ok for EFAULT :-)
> > No, of course, but that's consistent with the errno code since
> > _doserr_to_errno(5) = EACCES.
>
> I don't think this consistency matters too much. It's more important to
> tell the calling application something intelligent about why did the
> function fail.
Is it really more intelligent to return 2 (File not Found) or 3 (Path not
Found) when the path pointer or the result pointer are invalid, rather than
9 (memory block address invalid) that gives EFAULT ?
> The reason for this request is, as I explained, that it makes it easier
> to review the changes. There are no other principles beyond that. I
> agree that sometimes the old code could be made more readable, but I'm
> asking not to mix real changes with cosmetic ones.
Another reason why I did that is I found that dos/dir/findfirst.c and
dos/dir/findnext.c are better written than dos/compat/d_findf.c and
dos/compat/d_findn.c; since I almost entirely discarded the former files, I
choosed to put their materials in the latter.
> > I could turn the question...
> > See dos/dir/findfirs.c and dos/dir/findnext.c .
> > Consistency again.
>
> It's arguable, I think: _dos_findfirst _did_ use sizeof.
Yes, but the other solution (that of dos/dir/findfirs.c and
dos/dir/findnext.c) is better.
> > Why ? You must not pass an invalid handle to the function.
>
> Even if an invalid handle causes the user's disk to be wiped out? ;-)
Hey, that's the price to pay for writing bad code ! ;-)
Ok, you're right, I'll add a check.
> > Copy-pasted from dos/compat/d_findf.txh
>
> Yes, there are places in the docs where incorrect markup is used. That
> doesn't mean we should add new ones.
Obviously not, but that makes it a little hard to pick the right one :-)
> > Why ? the user must call _findclose() in all cases. findnext() doesn't
> > mention ENMFILE either and it's exactly the same situation.
>
> No, findnext doesn't require the application to close the handle, it does
> that itself. So in the case of findnext, if the application is not
> written to handle ENMFILE specially, it will report an error, but with
> _findnext, the application will leak search handles (or memory).
I don't see why, since _findclose() must be called in all cases: as soon as
_findnext() returns a non-zero value, _findclose() is called, then it's up
to the application to decide which errno code to handle (exactly like with
findnext).
> > Copy-pasted from dos/dir/findfirs.c and dos/dir/findnext.c
> > Using it instead of a mere sizeof() saves a lot of bytes.
>
> I don't understand: why does it save a lot of bytes? sizeof isn't a
> function.
Instead of transfering the whole structure to the DTA (~290 bytes), you
transfer only the meaningful part (~40 bytes).
--
Eric Botcazou
ebotcazou AT multimania DOT com
- Raw text -