View Issue Details

IDProjectCategoryView StatusLast Update
00006551003.1(2008)/Issue 7System Interfacespublic2024-06-11 08:52
Reporterdalias Assigned Toajosey  
PrioritynormalSeverityEditorialTypeEnhancement Request
Status ClosedResolutionAccepted As Marked 
NameRich Felker
Organizationmusl libc
User Reference
Sectionstrerror_r
Page Number1999
Line Number63229
Interp Status---
Final Accepted Text0000655:0001479
Summary0000655: Mark strerror_r obsolescent for next issue
DescriptionThe 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 ActionMark strerror_r obsolescent and recommend strerror_l as a replacement.
Tagsissue8

Relationships

related to 0000656 Closedajosey 1003.1(2013)/Issue7+TC1 Clearly allow or forbid thread-local storage for "static" buffers 

Activities

eblake

2013-02-21 18:16

manager   bugnote:0001470

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

dalias

2013-02-21 18:49

reporter   bugnote:0001472

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.

geoffclare

2013-02-22 10:38

manager   bugnote:0001476

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

geoffclare

2013-02-28 16:40

manager   bugnote:0001479

Last edited: 2013-02-28 16:54

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.

Issue History

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