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

> 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.

- Raw text -