[Pkg-gnupg-maint] libgpg-error symbol visibility

Werner Koch wk at gnupg.org
Fri Sep 12 18:35:03 UTC 2014


On Fri, 12 Sep 2014 17:54, dkg at fifthhorseman.net said:

> I'm used to a convention where a symbol with a leading underscore is
> "private" or internal, and i would try to avoid exporting it from a
> shared library.  Is this something i should be concerned about?  If

No, these are on purpose.  Two are the helper functions for getc and
putc macros, _gpgrt_get_std_stream is used to implement gpgrt_stdin et
al. macros and _gpgrt_set_std_fd is only used for WindowsCE but exported
anyway maybe for regression tests or such.

> other _-prefixed functions show up in the list of exported symbols by
> accident, should i report them as a concern?

If you notice them, please report.

> Out of curiosity -- why "rt"?  And while i'm on the human-understanding
> kick: I think the README is out-of-date with the recent changes, and
> could probably use a brief update.

"rt" = RunTime support for gpg.  There is quite some code source copied
by all gnupg related libraries which benefit from being in a library of
its own.  The real reason why this will eventually be needed (in
particular file related functions) is that there is plan for native
Windows 64 support.  Over there we have the problem that a Windows
HANDLE does not fit into an "int" bug we need a common object for
sockets and fds and sometimes HANDLES.  Even the current code for 32 bit
Windows is hard to debug and at some places we have more or less to
guess what kind of object this is and call the appropriate function.  A
common runtime layer will help with portability.

> Can you point me toward that fix?  It would help me to understand the
> problem more clearly.

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commitdiff;h=c307e1f801cd9a25c4a5b9a90073362219d52ee6

And look into estream.c:do_close

> In this scenario, the gpg-error atexit handler wouldn't get called,
> right?  Unless gpg-error is initialized early, in which case some other
> atexit() handler might be the one that falls off the stack.

I general yes, unless other libs are using a constructor with atexit.
But I doubt that this will ever happen.  We would have more problems
than just libgpg-error.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Pkg-gnupg-maint mailing list