Date: Sun, 10 Jun 2001 20:04:08 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: dj AT delorie DOT com Message-Id: <9003-Sun10Jun2001200407+0300-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: <200106101441.KAA11909@envy.delorie.com> (message from DJ Delorie on Sun, 10 Jun 2001 10:41:56 -0400) Subject: Re: confstr v2 References: <200106101441 DOT KAA11909 AT envy DOT delorie DOT com> 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 > Date: Sun, 10 Jun 2001 10:41:56 -0400 > From: DJ Delorie > > > The Posix draft standard clearly says that the result of confstr should > > not depend on the changes to environment variables such as PATH made by > > users or applications. I just thought that DJDIR should be treated > > similarly. > > True, but in our case it depends on nothing *but* environment > variables, so what can we do? It's going to depend on what the user > sets for DJDIR in their environment no matter how careful we are, so > given that, I don't think we need to be overly paranoid about what > happens to the environment after the user is done fiddling with it. > > At the very least, implement confstr in C++ and use a global > constructor to stash away the value of $DJDIR so programs that never > call confstr aren't burdened by the code to save it. Is code bloat and performance hit to programs which don't use confstr the only consideration that worries you? If so, how about if the original value of DJDIR is not stashed away by the startup code unless confstr is linked in? One way to do that would be to have confstr.c initialize a global function pointer, which the startup code will call only if it is non-NULL. That function could then be implemented in confstr.c, and do the actual work of saving DJDIR's value.