[gnutls-devel] Automatic library initialization
Andrew W. Nosenko
andrew.w.nosenko at gmail.com
Mon Nov 16 22:50:00 CET 2015
On Mon, Nov 16, 2015 at 7:57 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:
> On Mon, Nov 16, 2015 at 6:10 PM, Andrew W. Nosenko
> <andrew.w.nosenko at gmail.com> wrote:
> >> >> Something like the following. Have each program not wishing to use
> >> >> global initialization to define a symbol which overrides a weak one
> >> >> from gnutls. In practice that would mean setting:
> >> >> GNUTLS_SKIP_GLOBAL_INIT
> >> >> in some global section in your program. That can also be easily
> >> >> backported in 3.3.x and you can check for that feature with an ifdef.
> >> >> Would that be acceptable?
> >> > Brilliant idea. I'll use it for my projects... but other projects
> won't
> >> > benefit immediately (they first have to know).
> >> I'll then include it in 3.4.x and 3.3.x releases.
> > First at all, IMHO, _current_ API, which eliminates requirement to call
> > explicitly some init function is a good. And the "old-style API" with
> > requirement to call some init function before any thread and/or child
> > processes will be forked, which you want to resurrect, is a bad.
>
> I believe you misunderstood the intention. There will be a way for
> certain applications to disable the "automatic" initialization.
> Otherwise, all other applications and libraries will take advantage of
> that, and need not to call gnutls_global_init().
>
>
I understood the intention. Just a solution is fragile, if my assumption
is correct.
Assumption: library can inadvertently or intentionally define "hard"
symbol. It will overplay the weak symbol in GnuTLS. It affects the whole
process, not the only library, which set that symbol. So, we have library,
which functioning as intended (or not, it depends), and all other pieces of
process, which are damaged.
--
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151116/786fd905/attachment-0001.html>
More information about the Gnutls-devel
mailing list