[PATCH] Report dlsym, dlvsym lookup errors using dlerror [BZ #19509]

[Martin Sebor]

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.

Martin

>
> 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).
>
> Cheers,
> Carlos.
>