From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10110111847.AA16991@clio.rice.edu>
Subject: Re: _findfirst() patch
To: djgpp-workers AT delorie DOT com, ebotcazou AT libertysurf DOT fr
Date: Thu, 11 Oct 2001 13:47:15 -0500 (CDT)
In-Reply-To: <006601c15277$3736ab00$d27824d5@zephyr> from "Eric Botcazou" at Oct 11, 2001 07:05:12 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

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

Let me clarify - if the handle is still open and valid, it should be 
returned so _findclose could clean it up.  You had asked about the
question of when our internal findfirst closes the handle for you 
because there were no wild cards.  In that case _findclose would be
able to recognize it as already being closed and do nothing.

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

I'm not happy about a lot of these.  Given time I'd like to clean them up,
but until then not making it any worse is a good thing :-)

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

This may be the best fix.  I believe Eli also said this might be the way
to go.  However, it depends on how much time and effort you are willing to
spend.  I personally would not object to putting your current versions
into the the library.  Consider the discussion as suggestions for 
improvement.