[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <em0161a10d-2175-4b96-9d2d-d14cd675eef9@elzian>
Date: Thu, 31 May 2018 14:20:19 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] scanf: handle the L modifier for integers
>Without this patch, ret will be 1 and mask will be 0. It is obviously
>incorrect. According to the man page, L should work like ll:
>
>L Indicates that the conversion will be either e, f, or g and the
> next pointer is a pointer to long double or the conversion will
> be d, i, o, u, or x and the next pointer is a pointer to long
> long.
This is a GNU extension. POSIX states that L is only valid before
a floating-point conversion specifier:
L
Specifies that a following a, A, e, E, f, F, g, or G conversion
specifier
applies to an argument with type pointer to long double.
from
http://pubs.opengroup.org/onlinepubs/9699919799/functions/scanf.html
So, it is valid for musl not to accept %Lx.
Now, the argument that it's a good idea to align musl's behaviour to
glibc's whenever possible is a sensible one. But it's a decision for
the musl authors to make, and the pros and cons need to be carefully
balanced; musl's current behaviour is not _incorrect_.
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
