[musl] strtoll() incompatibility

["(GalaxyMaster)" <galaxy@openwall.com.au>]

Hello,

I am not a true developer, so I don't have the POSIX standard handy, hence could
not quickly find whether the observed behaviour is correct or not.  I have two
systems, one is musl-based and the other is Glibc-based, so every time I stumble
upon something I check against Glibc.  I know that Glibc developers did quite a
few bespoke things, but this particular one made me wonder whether it is a bug
in musl.

Longs story short, it seems that musl's strto*() set errno when it is unable
to find a legitimate number at the begining of the string:
===
galaxy@musl:~/musl-tests $ cat strtoll.c 
#include <stdlib.h>
#include <limits.h>
#include <stdio.h>
#include <errno.h>

int main() {
   char *endptr, *str=" .25g ";
   long long val;

   errno = 0;
   val = strtoll(str, &endptr, 10);
   if (errno != 0) {
       perror("strtol");
       return 1;
   }

   if (endptr == str) {
       fprintf(stderr, "No digits were found\n");
       return 1;
   }

   printf("strtoll() returned %lld\n", val);

   if (*endptr != '\0')        /* Not necessarily an error... */
       printf("Further characters after number: \"%s\"\n", endptr);

   return 0;
}

galaxy@musl:~/musl-tests $ gcc -o strtoll strtoll.c 
galaxy@musl:~/musl-tests $ ./strtoll 
strtol: Invalid argument
galaxy@musl:~/musl-tests $
===

The output was from perror(), which indicates that the parsing produced an
error.  You can actually see how the parsing is done in src/stdlib/strtol.c.

At the same time the same code produces the following on a Glibc system:
===
[galaxy@archlinux musl-tests]$ ./strtoll 
No digits were found
[galaxy@archlinux musl-tests]$
===

Which basically tells me that Glibc's strtoll() did not set errno.

I don't know what the standard prescribes for this family of functions (I just
registered an account at Open Group to download the standard), but from the
common sense point of view a string not containing a number for these functions
is a valid argument, so responding with EINVAL does not seems to be right.

-- 
(GM)