This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]
- From: Martin Sebor <msebor at gmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 09 Feb 2016 15:19:46 -0700
- Subject: Re: [PATCH] Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]
- Authentication-results: sourceware.org; auth=none
- References: <56B9F83A dot 1000500 at redhat dot com> <56BA55C7 dot 6040505 at gmail dot com> <56BA5C0D dot 2040906 at redhat dot com>
On 02/09/2016 02:37 PM, Carlos O'Donell wrote:
On 02/09/2016 04:10 PM, Martin Sebor wrote:
On 02/09/2016 07:31 AM, Florian Weimer wrote:
I'm not sure if this is the right fix. I traced back the lack of error
reporting to the original addition of the RTLD_NEXT functionality. I
don't know why it was omitted from it.
I happened to come across the corresponding bug in Red Hat Bugzilla
and wanted to chime in on the patch.
POSIX requires dlerror() to return a non-null string after a dynamic
linking error. After a failed call to dlopen(), dlclose(), or dlsym(),
POSIX says that "More detailed diagnostic information shall be
available through dlerror()." dlerror() is required to return null
only when no error has occurred since the last call to the function,
or on failure. (It doesn't matter that RTLD_NEXT isn't fully
specified by POSIX.)
What does "failure" mean? The definition of the API is such that
if no symbol is found (is that an error or not?) then the function
returns NULL. So it might be seen as a normal form of operation
as opposed to real errors like ENOMEM.
My reading of the text in dlsym() (for example) is that a successful
completion implies that name refers to either a function or an object.
Otherwise "If handle does not refer to a valid symbol table handle
" or "if the symbol named by name cannot be found in the symbol table
associated with handle" that's a failure. The text doesn't explicitly
use the word failure but I think that's implied.
A POSIX clarification should probably be made here, but I agree
that from a QoI it is better to return some kind of error because
that's users expect. I also expect that's what other implementations
do (but haven't verified).