Date: Sun, 10 Jun 2001 15:36:27 -0400 Message-Id: <200106101936.PAA14115@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f From: DJ Delorie To: eliz AT is DOT elta DOT co DOT il CC: djgpp-workers AT delorie DOT com In-reply-to: <9003-Sun10Jun2001200407+0300-eliz@is.elta.co.il> Subject: Re: confstr v2 References: <200106101441 DOT KAA11909 AT envy DOT delorie DOT com> <9003-Sun10Jun2001200407+0300-eliz AT is DOT elta DOT co DOT il> 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 > Is code bloat and performance hit to programs which don't use confstr > the only consideration that worries you? Yes, pretty much. > If so, how about if the > original value of DJDIR is not stashed away by the startup code unless > confstr is linked in? That's what a static constructor would do. > 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. Using a static constructor means that nowhere else in djgpp need even know that such a technique is happening. We initialize conio the same way.