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 <dj AT delorie DOT com>
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: <Pine DOT SUN DOT 3 DOT 91 DOT 1010610104032 DOT 5638B-100000 AT is> <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.