This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12805] New: GNU strerror_r should always populate buf


http://sourceware.org/bugzilla/show_bug.cgi?id=12805

           Summary: GNU strerror_r should always populate buf
           Product: glibc
           Version: 2.13
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: eblake@redhat.com


Right now, it is impossible to write a program that works using either the GNU
or the XPG strerror_r signature.  That is because the GNU strerror_r does not
always populate buf, but expects the caller to use the returned pointer (the
returned pointer is equal to buf in the case where an "Unknown error nnn"
string was computed, but is distinct in the case where an untruncated known
error string was returned).  Of course, the contents put into buf might be
subject to truncation even though the distinct return pointer contains the
untruncated message, but an application can avoid that by using a large enough
buffer.

http://sourceware.org/bugzilla/show_bug.cgi?id=12782 just fixed XPG strerror_r
to always populate buf.  And by changing GNU strerror_r to likewise always
populate as much of buf as possible, you then make it possible for an
application to call strerror_r with a sufficiently large buffer size (hopefully
256 bytes is larger than any translation for any known error string), ignore
the return value, and thus use _either variant_ of strerror_r without regards
to the difference in return types, because buf will be usable as the resulting
message in both cases.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]