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
0000655 [1003.1(2008)/Issue 7] System Interfaces Editorial Enhancement Request 2013-02-08 19:30 2020-03-23 10:48
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Rich Felker
Organization musl libc
User Reference
Section strerror_r
Page Number 1999
Line Number 63229
Interp Status ---
Final Accepted Text Note: 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
Attached Files

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

-  Notes
(0001470)
eblake (manager)
2013-02-21 18:16

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).
(0001472)
dalias (reporter)
2013-02-21 18:49

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.
(0001476)
geoffclare (manager)
2013-02-22 10:38

(Response to Note: 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.
(0001479)
geoffclare (manager)
2013-02-28 16:40
edited on: 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 => Note: 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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker