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
