[Bug string/25343] New: strerror_r() and INT_MIN returns "Unknown error -18446744071562067968" (for x86_64)

[glibc at gmch dot uk]

https://sourceware.org/bugzilla/show_bug.cgi?id=25343

            Bug ID: 25343
           Summary: strerror_r() and INT_MIN returns "Unknown error
                    -18446744071562067968" (for x86_64)
           Product: glibc
           Version: 2.29
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: string
          Assignee: unassigned at sourceware dot org
          Reporter: glibc at gmch dot uk
  Target Milestone: ---

For unknown errors __strerror_r() does:

  p = _itoa_word (abs (errnum), &numbuf[20], 10, 0);

where abs(INT_MIN) is undefined.  As it happens, on x86_64 abs(INT_MIN) returns
INT_MIN, which is widened to unsigned long long int -- hence the silly result.

I guess absll(errnum) would fix the error where long long int is bigger than
int.

Otherwise, I dunno what hoops the library should be jumping through to allow
for not-2's-complement.

FWIW: the man-page mentions EINVAL and ERANGE errors, but is silent on whether
the GNU strerror_r() returns errors.  The implementation clearly does not
return any errors -- not even for buflen == 0 (with or without buf == NULL). 
[buf == NULL with buflen != 0 gives a SEGV -- duh.]

Also FWIW: the man-page, in general, talks of known/unknown error numbers and
valid/invalid error numbers, but does not say how or whether those are
different.  This is also true of POSIX.1 which is not a miracle of precision
either.  The glibc POSIX/XSI implementation clearly does not distinguish known
and valid, and 0 is known -- the function returns EINVAL for unknown error
numbers, as well as setting a string.  (Incidentally, if EINVAL is returned
that takes precedence over ERANGE, but that's also a secret.)

It would be nice to have a function to map an error number to its macro-name,
returning a constant string (for known) or NULL (for unknown) errors.  But
that's another story.

Chris

-- 
You are receiving this mail because:
You are on the CC list for the bug.