Subject: Re: HEADS UP: migration to fully dynamic linked "base" system
To: Johnny Billquist <firstname.lastname@example.org>
From: Noriyuki Soda <email@example.com>
Date: 08/27/2002 05:21:03
>>>>> On Mon, 26 Aug 2002 21:45:43 +0200 (CEST),
Johnny Billquist <firstname.lastname@example.org> said:
>> And even if there is a way to get such symbols. There is a still
>> following problem:
> And global state isn't the big problem, that I can see, but global
> information, such as errno, and global files, such as stdin, stdout and
> stderr. State variables are tied to the code, and if you run separate
> code, with separate state variables, you get no conflicts, even though
> both sets might be doing the same thing. It's just inefficient.
> (Someone will probably prove me wrong 3 seconds after I post this. :-)
Unfortunetely you are wrong as you imagined. ;-)
Think about the follows:
- program A calls ungetc() and DYNAMIC_FUNC() with
argument FILE *fp. And ungetc() is statically linked
with A, but DYNAMIC_FUNC() is called via dlopen().
- The DYNAMIC_FUNC() calls vscanf() internally,
but since A doesn't call vscanf() directly, vscanf() is
- Then, think about a case that internal handling of
FILE structure is somewhat different between old libc,
which is statically linked with program A, and new libc,
which is dynamically linked with DYNAMIC_FUNC().
In this case, ungetc() and vscanf() modify the fp
with inconsist way. This makes the program A fail to work.
This is not armchair theory. The way to handle _ub._base in FILE
structure was changed between NetBSD-1.5 and NetBSD-1.6.