mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] strtoll() incompatibility
@ 2021-10-13 14:06 (GalaxyMaster)
  2021-10-13 14:22 ` Shiz
  2021-10-13 14:28 ` Jₑₙₛ Gustedt
  0 siblings, 2 replies; 4+ messages in thread
From: (GalaxyMaster) @ 2021-10-13 14:06 UTC (permalink / raw)
  To: musl

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)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] strtoll() incompatibility
  2021-10-13 14:06 [musl] strtoll() incompatibility (GalaxyMaster)
@ 2021-10-13 14:22 ` Shiz
  2021-10-13 14:58   ` (GalaxyMaster)
  2021-10-13 14:28 ` Jₑₙₛ Gustedt
  1 sibling, 1 reply; 4+ messages in thread
From: Shiz @ 2021-10-13 14:22 UTC (permalink / raw)
  To: musl; +Cc: galaxy

Hi!

> ...
> 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),

No need to register, you can view the standard online here:
https://pubs.opengroup.org/onlinepubs/9699919799/

> 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.

From https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html:

These functions shall fail if:

[EINVAL]
  [CX] The value of base is not supported. 
[ERANGE]
  The value to be returned is not representable.
  These functions may fail if:

[EINVAL]
  No conversion could be performed.

> -- 
> (GM)

- Shiz

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] strtoll() incompatibility
  2021-10-13 14:06 [musl] strtoll() incompatibility (GalaxyMaster)
  2021-10-13 14:22 ` Shiz
@ 2021-10-13 14:28 ` Jₑₙₛ Gustedt
  1 sibling, 0 replies; 4+ messages in thread
From: Jₑₙₛ Gustedt @ 2021-10-13 14:28 UTC (permalink / raw)
  To: (GalaxyMaster); +Cc: musl

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

Hello,

on Wed, 13 Oct 2021 14:06:27 +0000 you ("(GalaxyMaster)"
<galaxy@openwall.com.au>) wrote:

> 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:
> ...

This function is actually in C, but the possible `errno` specification
comes seemingly from POSIX:

       The implementation may also set errno to EINVAL in case no
       conversion was performed (no digits seen, and 0 returned).

Jₑₙₛ

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] strtoll() incompatibility
  2021-10-13 14:22 ` Shiz
@ 2021-10-13 14:58   ` (GalaxyMaster)
  0 siblings, 0 replies; 4+ messages in thread
From: (GalaxyMaster) @ 2021-10-13 14:58 UTC (permalink / raw)
  To: musl

On Wed, Oct 13, 2021 at 04:22:22PM +0200, Shiz wrote:
> No need to register, you can view the standard online here:
> https://pubs.opengroup.org/onlinepubs/9699919799/

Bookmarked, thanks!

> From https://pubs.opengroup.org/onlinepubs/9699919799/functions/strtol.html:
> 
> These functions shall fail if:
> 
> [EINVAL]
>   [CX] The value of base is not supported. 
> [ERANGE]
>   The value to be returned is not representable.
>   These functions may fail if:
> 
> [EINVAL]
>   No conversion could be performed.

OK, if I read it correctly, that particular page is a bit confusing.  In
"RETURN VALUE", it says that both conditions for returning EINVAL are optional
extensions to the standard (this denoted by the CX link with arrows around both
sentences mentioning EINVAL, but in "ERRORS" only the base value error is
surrounded by that optional extension arrows. :-/

In any case, this is good enough for me to fix the application rather than
making a patch to musl :).  Thank you for your time and links!

-- 
(GM)

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-10-13 14:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-13 14:06 [musl] strtoll() incompatibility (GalaxyMaster)
2021-10-13 14:22 ` Shiz
2021-10-13 14:58   ` (GalaxyMaster)
2021-10-13 14:28 ` Jₑₙₛ Gustedt

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git