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

- Raw text -