Date: Thu, 11 Oct 2001 21:11:57 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Eric Botcazou" Message-Id: <1659-Thu11Oct2001211157+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: djgpp-workers AT delorie DOT com In-reply-to: <006601c15277$3736ab00$d27824d5@zephyr> (ebotcazou AT libertysurf DOT fr) Subject: Re: _findfirst() patch References: <10110111357 DOT AA18726 AT clio DOT rice DOT edu> <006601c15277$3736ab00$d27824d5 AT zephyr> 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 > From: "Eric Botcazou" > Date: Thu, 11 Oct 2001 19:05:12 +0200 > > > 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 ?) No, this is slightly different. _dos_findfirst only supports short file names, for compatibility with DOS MSC compilers. So it is not equivalent to findfirst. > 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). That's what I meant: take most of the guts of findfirst, move it to some new low-level function, and make both findfirst and _findfirst call that new function. > But it would > mean three more files because of the 'one function per file' rule. Don't worry about this, we don't have any problems with adding a few more modules to the library.