Date:	Sun, 14 Oct 2001 15:03:27 +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:	<00d301c154a5$510f9fc0$ef1924d5@zephyr>
Message-ID:	<Pine.SUN.3.91.1011014145628.17301J-100000@is>
MIME-Version:	1.0
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

On Sun, 14 Oct 2001, Eric Botcazou wrote:

> > Right, except that findfirst was there first, and _dos_findfirst
> > didn't seem like an important addition, so I guess no one looked very
> > hard inside it.
> 
> Would you agree to the following design ?
> 
>      findfirst(), _findfirst()
>                  |
>                  |
>                 / \
>         LFN=n  /   \  LFN=y
>               /     \
>              /       \
>  _dos_findfirst()  _lfn_findfirst()
>            |           |
>            |           |
>    function 4eh      function 714eh

This is okay, but note that it assumes that findfirst and _findfirst 
don't have any significant incompatibilities, in which case such a simple 
design will have difficulties.  For example, findfirst calls function 
714Eh with 1 in the SI register; if _findfirst should behave differently 
(e.g., return more accurate time stamps), you should augment the design.  
Similar considerations apply to the automatic closing of the lfn handle 
which findfirst does.

With that caveat, I think this is a good design.

> This way there would be no low-level code duplicated. This would also mean
> that _lfn_findfirst() would always fail if LFN=n. As it is not meant to be
> directly called by the user, I don't think it's a problem.

It is okay even if it _is_ meant for the user: as long as a function is 
documented to only work under LFN, there's no problem.

Thanks.

- Raw text -