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
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


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