Date:	Thu, 11 Oct 2001 13:49:57 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Eric Botcazou <ebotcazou AT libertysurf DOT fr>
cc:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	Re: _findfirst() patch
In-Reply-To:	<008701c15237$58c3f240$de1c24d5@zephyr>
Message-ID:	<Pine.SUN.3.91.1011011134758.20553G-100000@is>
MIME-Version:	1.0
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

On Thu, 11 Oct 2001, Eric Botcazou wrote:

> > 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).

If this is the reason, you could rewrite findfirst so that it calls 
_findfirst.

> > 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.

Think about programs which call both findfirst and _findfirst (this can 
happen, since some library functions call findfirst internally).

- Raw text -