X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10112300432.AA14322@clio.rice.edu>
Subject:	Re: lfn from scratch...
To:	djgpp-workers AT delorie DOT com
Date:	Sat, 29 Dec 2001 22:32:42 -0600 (CST)
Cc:	wojciech DOT galazka AT polkomtel DOT com DOT pl, eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
In-Reply-To:	<2427-Sat29Dec2001224024+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Dec 29, 2001 10:40:24 PM
X-Mailer:	ELM [version 2.5 PL2]
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

> > > This is not an application-level issue: if some drives don't support
> > > the LFN API, _all_ applications on that system will have to modify
> > > the way they use the result of _USE_LFN.
> > 
> > Either modify or assume that no drive supports LFN API
> > because the default drive does not support it and libc calls _use_lfn(0) to 
> > check for LFN API support
> > Or I'm wrong there ?
> 
> Some of the library functions do call _use_lfn with a non-NULL file
> name argument. 

My understanding is that we should really have *all* calls to _use_lfn
in the library be called with the file name we want to operate on
(or at least the disk letter).

> > > Since this applies to all programs, simply replacing _use_lfn with a
> > > custom version will do what you want.  So I don't see a reason to
> > > invent an application-level feature like the one you suggest.
> > 
> > It's easier to put a custom version of _use_lfn in a separate library 
> > than to modify libc itself.
> 
> Perhaps; but that, too, does not require any handler, just a
> replacement in a separate library.

I don't understand the problem - I think we should fix libc to do the
right thing instead of expecting an application to hook in and try to
fix it?

- Raw text -