View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000639 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2013-01-01 21:16 | 2013-01-10 17:11 |
| Reporter | dalias | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Error |
| Status | Closed | Resolution | Rejected | ||
| 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. | ||||
| has duplicate | 0001110 | Closed | 1003.1(2016/18)/Issue7+TC2 | Return requirements for error on dlclose too restrictive for implementors. |
|
|
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. |
| 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 |
| 2017-01-04 12:16 | geoffclare | Relationship added | has duplicate 0001110 |
