[Bug libc/840] New: strerror_r() not conforming to SUSv3

[Bug libc/840] New: strerror_r() not conforming to SUSv3

[gwesp at flyelite dot ch]

According to SUSv3, strerror_r() should return an int.

-- 
           Summary: strerror_r() not conforming to SUSv3
           Product: glibc
           Version: 2.3.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: gwesp at flyelite dot ch
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=840

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/840] strerror_r() not conforming to SUSv3

[gotom at debian dot or dot jp]

------- Additional Comments From gotom at debian dot or dot jp  2005-06-01 15:39 -------
Please read string/string.h:

/* Reentrant version of `strerror'.
   There are 2 flavors of `strerror_r', GNU which returns the string
   and may or may not use the supplied temporary buffer and POSIX one
   which fills the string into the buffer.
   To use the POSIX version, -D_XOPEN_SOURCE=600 or -D_POSIX_C_SOURCE=200112L
   without -D_GNU_SOURCE is needed, otherwise the GNU version is
   preferred.  */


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME


http://sources.redhat.com/bugzilla/show_bug.cgi?id=840

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/840] strerror_r() not conforming to SUSv3

[gwesp at flyelite dot ch]

------- Additional Comments From gwesp at flyelite dot ch  2005-06-02 08:13 -------
Needless to say that for any serious and efficient kind of SW engineering, it is
completely out of question to have the user scan the header files (!) in order to 
be able to find details which should be in the documentation.  I acknowledge that
I should have defined POSIX_C_SOURCE, but the manual is clearly misleading in that
it gives the impression that the GNU version of strerror_r() is the only one
present.

IMHO the non-standard GNU version should be renamed to gnu_strerror_r() or
similar to avoid confusion.  Otherwise, hundreds of developers will stumble into
the same trap in the future.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=840

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.