0000639: dlsym, dlclose handling of invalid handles - Austin Group Defect Tracker

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

ID

Category

Severity

Type

Date Submitted

Last Update

0000639

[1003.1(2008)/Issue 7] System Interfaces

Editorial

Error

2013-01-01 21:16

2013-01-10 17:11

Reporter

dalias

View Status

public

Assigned To

ajosey

Priority

normal

Resolution

Rejected

Status

Closed

Name

Rich Felker

Organization

musl libc

User Reference

Section

dlsym, dlclose

Page Number

unknown

Line Number

unknown

Interp Status

---

Final Accepted Text

Summary

0000639: dlsym, dlclose handling of invalid handles

Description

As written, the specification of dlsym and dlclose seems to require them to detect and report an error on attempts to use an invalid handle. Under RETURN VALUE:

"If handle does not refer to a valid object opened by dlopen(), or if the named symbol cannot be found within any of the objects associated with handle, dlsym() shall return NULL. More detailed diagnostic information shall be available through dlerror ."

and

"If the object could not be closed, or if handle does not refer to an open object, dlclose() shall return a non-zero value. More detailed diagnostic information shall be available through dlerror()."

This requirement seems to place an unnecessary burden on implementations that they iterate through a list of open libraries to verify that the argument is actually the handle for one, whereas efficient implementations would want to use the argument directly as a pointer. This is especially important for dlsym where performance may be relevant, and validating the library handle could easily turn a constant-time search (in the case where the symbol is known to be defined in the library itself) to a linear (or at best, logarithmic) time operation.

Desired Action

Strike the text about not referring to a valid object from the return value sections, yielding:

"If the named symbol cannot be found within any of the objects associated with handle, dlsym() shall return NULL. More detailed diagnostic information shall be available through dlerror ."

and

"If the object could not be closed dlclose() shall return a non-zero value. More detailed diagnostic information shall be available through dlerror()."

Further, add text to the descriptions reading: "If handle does not refer to a valid object opened by dlopen(), the behavior is undefined."

Tags

No tags attached.

Relationships

has duplicate

Closed

1003.1(2016/18)/Issue7+TC2

Return requirements for error on dlclose too restrictive for implementors.

Notes
(0001443) Don Cragun (manager) 2013-01-10 17:09 edited on: 2013-01-10 17:11	Although some sets of interfaces in the standard do not require the system to maintain a list of active objects, some applications do depend on this behavior with shared libraries. Forcing the kernel to keep track of active shared library handles should not be a big performance hit even if the implementation just keeps a linear list of open handles. (If a system expects large numbers of shared libraries to be linked in at run time, the system can certainly optimize the search of active handles.) There isn't much difference (other than the type of object involved) in having the kernel report an EBADF error if given a bad file descriptor and having the kernel report a bad shared library handle. Although we realize that the standard I/O package does not behave this way, we know that applications sometimes pass bad stream handles to stdio routines and can't detect the error until much later. Therefore, we choose to reject this suggestion.

Issue History
Date Modified	Username	Field	Change
2013-01-01 21:16	dalias	New Issue
2013-01-01 21:16	dalias	Status	New => Under Review
2013-01-01 21:16	dalias	Assigned To	=> ajosey
2013-01-01 21:16	dalias	Name	=> Rich Felker
2013-01-01 21:16	dalias	Organization	=> musl libc
2013-01-01 21:16	dalias	Section	=> dlsym, dlclose
2013-01-01 21:16	dalias	Page Number	=> unknown
2013-01-01 21:16	dalias	Line Number	=> unknown
2013-01-10 17:09	Don Cragun	Note Added: 0001443
2013-01-10 17:11	Don Cragun	Note Edited: 0001443
2013-01-10 17:11	msbrown	Interp Status	=> ---
2013-01-10 17:11	msbrown	Status	Under Review => Closed
2013-01-10 17:11	msbrown	Resolution	Open => Rejected
2016-12-24 04:59	Florian Weimer	Issue Monitored: Florian Weimer
2017-01-04 12:16	geoffclare	Relationship added	has duplicate 0001110

Mantis 1.1.6[^]

Copyright © 2000 - 2008 Mantis Group