From: "Eric Botcazou" <ebotcazou AT libertysurf DOT fr>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Benchmarks Revisited...
Date: Fri, 5 Oct 2001 10:39:15 +0200
Lines: 26
Message-ID: <9pjrpe$1i64$1@news5.isdnet.net>
References: <5l6irt41k9kns8h3j3398rm282b56b6m69 AT 4ax DOT com> <5567-Tue02Oct2001102723+0300-eliz AT is DOT elta DOT co DOT il>
NNTP-Posting-Host: dyn-213-36-136-226.ppp.libertysurf.fr
X-Trace: news5.isdnet.net 1002271342 51396 213.36.136.226 (5 Oct 2001 08:42:22 GMT)
X-Complaints-To: abuse AT isdnet DOT net
NNTP-Posting-Date: 5 Oct 2001 08:42:22 GMT
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> > _findfirst / _findnext / _findclose.... sheesh!

> Perhaps you could write up a compatibility layer and submit it for
> inclusion in a future DJGPP version.

We just did that for Allegro 3.9.39 WIP because DJGPP libc's
findfirst/findnext are not portable at all (time format).

I think the Watcom libc is right here: it provides both the legacy DOS
_dos_findfirst/_dos_findnext functions (DOS time format) and the Windows,
OS/2 compatible _findfirst/_findnext/_findclose functions (ANSI time
format).

The only drawback of _findfirst/_findnext/_findclose is that you can't
specify a set of attributes to search the file against, but it's not that
important since you can exclude files afterward.

Would you be ok to include the Watcom, Windows, OS/2 compatible _find* set
of functions in the DJGPP libc ? If so and if no one has already started to
do it, I can code it and submit it for approval.

--
Eric Botcazou
ebotcazou AT multimania DOT com