|
Message-ID: <20180531190021.GA9758@outlook.office365.com> Date: Thu, 31 May 2018 12:00:22 -0700 From: Andrei Vagin <avagin@...tuozzo.com> To: musl@...ts.openwall.com, Laurent Bercot <ska-dietlibc@...rnet.org> Cc: alpine-devel@...ts.alpinelinux.org 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_. It is incorrect, because scanf() has to return 0, or it has to handle the L modifier. Currently it doesn't handle L and return 1, so the application can't detect this issue. I would prefer a case when musl works like glibc, if there are not any reason to not to do that. For example, now Alpine Linux is very popular and there are a lot of packages. In many cases, a maintainer, who adds a new package, fixes compile-time errors and doesn't run any tests. A target application can work differently with musl comparing with glibc due to this sort of issues.
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.