This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]