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