Date: Sun, 14 Oct 2001 15:03:27 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Eric Botcazou cc: DJGPP workers Subject: Re: _findfirst() patch In-Reply-To: <00d301c154a5$510f9fc0$ef1924d5@zephyr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.