Message-ID: <006601c15277$3736ab00$d27824d5@zephyr>
From: "Eric Botcazou" <ebotcazou AT libertysurf DOT fr>
To: "DJGPP workers" <djgpp-workers AT delorie DOT com>
References: <10110111357 DOT AA18726 AT clio DOT rice DOT edu>
Subject: Re: _findfirst() patch
Date: Thu, 11 Oct 2001 19:05:12 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Reply-To: djgpp-workers AT delorie DOT com

> In this case I would say pass back a known "already closed" handle so
> the _findclose() is a no operation.  If the handle is "finished" it would
> be useless anyway.

Is that solution really safe ? I don't know if this would really be useful
but one could imagine something like:

    handle = _findfirst("*.dat", &fileinfo);

    while (number_of_dat_file < 100) {
        if (_findnext(handle, &fileinfo) == 0)
            number_of_dat_file++;
        else
            create_new_dat_file();
    }

    _findclose(handle);

> The current findfirst code is linked into (almost) every image anyway
> to handle command line wild card expansion (unless you explicitly
> disable it).  So attempting to use a common code base makes both library
> size sense, exe size sense and maintainability sense - if possible.

I wasn't aware of that. You're obviously right.

> If you have to put special handling code in the library you end up having
> to patch multiple places instead of a single location (we have a nightmare
> in our seek implementations today).

I agree that's not the funniest thing to deal with (may I let you remark
though that the same situation already exists for libc/dos/dir/findfir.c and
libc/dos/compat/d_findf.c, same thing for src/libc/dos/dir/findnext.c and
src/libc/dos/compat/d_findf.c ?)

Then I think a better solution than a high-level wrapper could be a
low-level wrapper on top of which both findfirst() and _findfirst() woud
live: it would be as close as possible to the DOS functions (DOS time
format, handle exposed, no automatic release of the handle). But it would
mean three more files because of the 'one function per file' rule.

--
Eric Botcazou
ebotcazou AT multimania DOT com