Date: Thu, 31 May 2018 12:00:22 -0700
From: Andrei Vagin <avagin@virtuozzo.com>
To: musl@lists.openwall.com, Laurent Bercot <ska-dietlibc@skarnet.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] Re: [PATCH] scanf: handle the L modifier for integers
Message-ID: <20180531190021.GA9758@outlook.office365.com>
References: <20180531064719.6805-1-avagin@virtuozzo.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20180531064719.6805-1-avagin@virtuozzo.com>
User-Agent: Mutt/1.9.3 (2018-01-21)
Received-SPF: None (protection.outlook.com: virtuozzo.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2018 19:00:31.2460 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 
	edc37dcc-dd92-4bc6-9a0d-08d5c728c8d9
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3254

>>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.


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---