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

gcc at gmch dot uk gcc-bugzilla@gcc.gnu.org
Fri Jan 3 15:02:00 GMT 2020


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93145

            Bug ID: 93145
           Summary: strerror_r() and INT_MIN returns "Unknown error
                    -18446744071562067968" (for x86_64)
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc 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


More information about the Gcc-bugs mailing list