0000655: Mark strerror_r obsolescent for next issue

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

Aardvark Mark IV