Date: Sun, 21 Jul 1996 17:04:33 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
Cc: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
Subject: Re: find41b slow behaviour.....
In-Reply-To: <199607211301.JAA28023@delorie.com>
Message-Id: <Pine.SUN.3.91.960721165551.6686B-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Sun, 21 Jul 1996, DJ Delorie wrote:

> > As far as `_use_lfn' goes, shouldn't looking at LFN in the environment on 
> > every call do the trick?  It will make it a bit slower, but it is the 
> > right thing IMHO (the bit in startup flag should override LFN value).
> 
> I think once per startup and once after reading djgpp.env should be
> enough.  We just need to make sure that it actually gets set right
> regardless of the combination of unexec, djgpp.env, and $LFN.

`unexec' already takes care of itself: I submitted a patch which will be 
in 19.32 (RSN) that momentarily switches off the no-LFN bit in the 
startup flags during the dumping, then restores the bits as they were.  
(This allows Emacs to be built on non-LFN platform, then be used with 
LFN=y on another platform.)

But I'm concerned about looking at $LFN only at certain times.  What
should a user expect if a program sets $LFN at runtime, for instance?  I
can think of a few cases where this might be needed, like a Makefile that
sets $LFN.  Wouldn't it be safer to just always test $LFN?  It shouldn't
be too expensive, should it?  If it is, maybe we should make `setenv' and
`putenv' flip the LFN bit.