View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000655 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2013-02-08 19:30 | 2024-06-11 08:52 |
| Reporter | dalias | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Rich Felker | ||||
| Organization | musl libc | ||||
| User Reference | |||||
| Section | strerror_r | ||||
| Page Number | 1999 | ||||
| Line Number | 63229 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0000655:0001479 | ||||
| Summary | 0000655: Mark strerror_r obsolescent for next issue | ||||
| Description | The strerror_r function is problematic because there are historically at least two versions, and at least one major implementation, the GNU C Library, seems committed to providing a version incompatible with the version specified in the standard. While an attempt is made in glibc to provide a conforming version when the proper feature test macros are defined, the workaround is header-based and is in fact non-conforming since it does not support applications that omit inclusion of string.h and declare the function manually. The strerror_l function is mandatory beginning with issue 7, provides a much easier-to-use interface to the same functionality, and does not have incompatible historical versions of the interface that can interfere with application compatibility. | ||||
| Desired Action | Mark strerror_r obsolescent and recommend strerror_l as a replacement. | ||||
| Tags | issue8 | ||||
|
|
This was discussed on 21 February 2013, but no resolution reached. Discussion hinged on a question raised in the mailing list, on whether an application is required to #include <string.h> before it can use strerror_r. A strict reading of (XSH 2.1.1 Use and Implementation of Functions, 4) concludes that since size_t is only available after including a header, then a header must be included; but there was concern over whether that requirement is too tight (is include <sys/types.h> for size_t and then hand-declaring strerror_r acceptable?) or too loose (many implementations have open vs. open64, where you only get the right version for large file compilation if you include <fcntl.h>, even though open can be hand-declared without headers). |
|
|
In response to note #0001470, I think that's a separate issue. I believe the way glibc is doing large file support is non-conforming for multiple reasons, including both the header issue (e.g. open) and the fact that names like open64 are in the namespace reserved for the application, but if you believe the standard should allow such things, a new issue should be opened to address it. The issue I've reported here in this issue report is simply that strerror_r is problematic because of conflicting historical versions of the function and no longer necessary now that strerror_l (which also happens to have a much more convenient interface) is required by the standard and offers thread-safe access to error strings. |
|
|
(Response to 0000655:0001472) As far as the standard is concerned, the only problem with glibc's strerror_r() is that you get the wrong version if you declare it yourself. Therefore the resolution very much hinges on the interpretation of XSH 2.1.1 rule 4. In practice, application writers may also get a problem if they neglect to define _POSIX_C_SOURCE or _XOPEN_SOURCE before including <string.h>, but those writers are not following the standard and therefore there is nothing the standard can do to solve that problem. Such applications are likely to suffer any number of non-conforming behaviours besides that of strerror_r(), since it has historically been established practice to use feature test macro checks as one way to resolve conflicts between standard behaviour and historical behaviour. For example, Solaris does it for printf(), scanf(), and various wide character and wide string functions. |
|
|
At page 467 line 15871 section 2.1.1 change: Provided that a function can be declared without reference to any type defined in a header, it is also permissible to declare the function explicitly and use it without including its associated header. to: For functions from the C Standard only, provided that the function can be declared without reference to any type defined in a header from the C Standard, it is also permissible to declare the function explicitly and use it without including its associated header. At page 2000 line 63279 section strerror() add a new paragraph to APPLICATION USAGE: Applications should use strerror_l() rather than strerror() or strerror_r() to avoid thread safety and possible alternative (non-conforming) versions of these functions in some implementations. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-02-08 19:30 | dalias | New Issue | |
| 2013-02-08 19:30 | dalias | Status | New => Under Review |
| 2013-02-08 19:30 | dalias | Assigned To | => ajosey |
| 2013-02-08 19:30 | dalias | Name | => Rich Felker |
| 2013-02-08 19:30 | dalias | Organization | => musl libc |
| 2013-02-08 19:30 | dalias | Section | => strerror_r |
| 2013-02-08 19:30 | dalias | Page Number | => unknown |
| 2013-02-08 19:30 | dalias | Line Number | => unknown |
| 2013-02-21 17:05 | eblake | Relationship added | related to 0000656 |
| 2013-02-21 18:16 | eblake | Note Added: 0001470 | |
| 2013-02-21 18:49 | dalias | Note Added: 0001472 | |
| 2013-02-22 10:38 | geoffclare | Note Added: 0001476 | |
| 2013-02-28 16:40 | geoffclare | Note Added: 0001479 | |
| 2013-02-28 16:42 | geoffclare | Interp Status | => --- |
| 2013-02-28 16:42 | geoffclare | Final Accepted Text | => 0000655:0001479 |
| 2013-02-28 16:42 | geoffclare | Status | Under Review => Resolved |
| 2013-02-28 16:42 | geoffclare | Resolution | Open => Accepted As Marked |
| 2013-02-28 16:43 | geoffclare | Tag Attached: issue8 | |
| 2013-02-28 16:47 | geoffclare | Page Number | unknown => 1999 |
| 2013-02-28 16:47 | geoffclare | Line Number | unknown => 63229 |
| 2013-02-28 16:54 | geoffclare | Note Edited: 0001479 | |
| 2020-03-23 10:48 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 08:52 | agadmin | Status | Applied => Closed |
