Mail Archives: djgpp-workers/2001/10/11/05:32:48
> These functions look so identical to the current ones to me that it looks
> like _find* could just be a wrapper around the current find* routines.
I examined the wrapper solution and I eventually didn't choose it because:
- the possible problem with the handle (see below),
- while Borland findfirst()'s semantics was the right one for int 21h
function 4eh, I think Watcom's _findfirst() is the right one for int 21h
function 714eh which explicitly makes use of a handle. I found it a bit
convoluted to first hide the handle in a structure and then expose it
through the interface,
- I was told the implementation (wrapper or low-level function) doesn't
really matter.
But I can make the wrapper version if you do want it.
> The return arguments and data structures might be different, but at a
> quick glance I didn't see anything unique to either set of calls.
Maybe the use of the handle: when findfirst() detects no wildcard in the
pathname or findnext() doesn't find any more files, they automatically
release the handle. I don't think that's the semantics of _findfirst() and
_findnext(), given that there is precisely _findclose() to do it (although
the Watcom docs doesn't say anything about that case).
> Making the new routines a wrapper around the current ones would seem
> to minimize low level code (improve maintenance), decrease code size.
A wrapper would certainly minimize low-level code but I don't understand why
it would decrease code size: we are talking about a library and IMHO the
size that matters is the size of code that gets linked to the user program.
Then a wrapper would obviously increase the code size.
--
Eric Botcazou
ebotcazou AT multimania DOT com
- Raw text -