From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12867 Path: news.gmane.org!.POSTED!not-for-mail From: Andrei Vagin Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [PATCH] scanf: handle the L modifier for integers Date: Thu, 31 May 2018 14:21:09 -0700 Message-ID: <20180531212108.GA21069@outlook.office365.com> References: <20180531064719.6805-1-avagin@virtuozzo.com> <20180531190021.GA9758@outlook.office365.com> <20180531224442.3bc8dcdc@ncopa-desktop.copa.dup.pw> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r X-Trace: blaine.gmane.org 1527801576 9761 195.159.176.226 (31 May 2018 21:19:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 21:19:36 +0000 (UTC) User-Agent: Mutt/1.9.3 (2018-01-21) Cc: musl@lists.openwall.com, Laurent Bercot To: Natanael Copa Original-X-From: musl-return-12883-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 31 23:19:32 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fOUym-0002MO-OO for gllmg-musl@m.gmane.org; Thu, 31 May 2018 23:19:28 +0200 Original-Received: (qmail 20167 invoked by uid 550); 31 May 2018 21:21:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20148 invoked from network); 31 May 2018 21:21:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nvO+tT/E62SaBxXO+BZoJHl6HG4vxXlN1tJmujvIizI=; b=A+YaUVeLB6srpSCgkC+6Ijk0vRIQ1uze0/UKyiRTzliHP8psXg03h794Rl46jbU58sYWD1ctERUWFNHokw0huXqztSaKuAngzXL3FxuC4x43u2RL/8vlTKPVg6gsZSPsqsf+HWuIUUMVp+98h394K38TG64000c1JPBFgHPO4kY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=avagin@virtuozzo.com; Content-Disposition: inline In-Reply-To: <20180531224442.3bc8dcdc@ncopa-desktop.copa.dup.pw> X-Originating-IP: [4.16.175.162] X-ClientProxiedBy: MWHPR13CA0032.namprd13.prod.outlook.com (2603:10b6:300:95::18) To AM0PR08MB3252.eurprd08.prod.outlook.com (2603:10a6:208:5e::21) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020);SRVR:AM0PR08MB3252; X-Microsoft-Exchange-Diagnostics: 1;AM0PR08MB3252;3:JznUfaeD5H688QP7WMH1mqTZSIpKRB6USkw113JmXO8xbLM5mgyEYUyRp3kcRVIVvV9LnuQPVPLeVvkzfoRmfrhKyAew41GRa5iDUFbhcAU4BXh/brjGRw3iMQlTzTvicNA+1nhOkPl3uihCFiS9HqwW5IF5VWHhgXwC6gvJ4N5vQ7Yl0rr6YSyk6HU7ipvoTayLZPeosjEXtSbGcKzC9rjR71KEzQgZHfXnlDMt6zaL++qu7r07Zndr6+BsuNCV;25:3Qk0Rn80mOoVSPl4lr7UZWHKnI40hqz/Q9QL7zOshYfgT9sZzlz0EOh1CviF0UeG+pO0aXWRAo0vrSoqBcQwiE5RxNyMBnAhIUD9neqabwhSu/j5tW5XRZhBb8hkyM7KwAsUFgQcch/UV2zITHEt3bDoVHyxVltX2o0GSQe8/mPN7vR0ejjV04l14CcH1YtoQab6lp01qqMrmzPkmvQhKPRuAffuzhZezFkucgD4AWcPuW1oAc6FhFRTMY5KFCSJ3NqZLR6gCA2dhpqMg6J/GGpTZxkcS2BJoqpENkQajPRBTip9YD8mFV1H3QyM7zlpku6DuCLZfZod/mm8xgwyEg==;31:fVtKwa22QSYr+y8NG9e1mPR5pd1ci2x7s4ftvCThY/oDy8dMD6Emclp4OrM6fZz1izbkSeDTY/oQiictXaxtT+BIcRY7TeNZYclbRp0/aCqCZ5RwzrlCIaNVITvIAfEhrEh25idAqDTBpzGwTO3be9kq9mblJuWD7jHYdWAJLCu7C qm8sGpxELYgTcMH3C3PVHmMs+fB19NRos2QgVcnCmmB8Xre34ap69gU0Cuolzc= X-MS-TrafficTypeDiagnostic: AM0PR08MB3252: X-Microsoft-Exchange-Diagnostics: 1;AM0PR08MB3252;20:SLNzbpTlu4Pr660U4dGK1E4LkSNlD2+iYjIwHuCzu9A9lH9BqQbg0AkpC23ydfMblXHyayvLh7Vz2qhV44QnbNaIop35S+OwFKdCiBO1dQaVK9zLR1DhzyW0f58Sr/NsiSF5ev5+RAD1+vrX+tq9YJDSTBiU4XcpKtxmBh/mKj0lQjRt+0HKiSAlNJToXqrJuyIqV/mORNhOB+IVaXwhI18279EGXWXCvLXUSwBI/WzXyNBCZdoG4I2LfYxE0/KEdTLBEAj1xckPNHn3erLLlh2J5xV59H2BWSL9rCiXR6B9wxG1P8OeVdrmv1IPFEGSzaf64eKAnPoHercyy4I5g+zWfpWGl74/a/RkvzV0ymuVmeGWwRvMFPWMg/XKcvN7Rpl/clqSSV+VKx8mVriqoRQhNnI6Ll37NuU/OwPGCqYUm91mtYYRMTC2Ly1py2Sb9Qa2dM5hC/yInnRxVgcBfWIJErnjaFyOTdX5d8u56cW4VRYsBiwh3JC8gJtnEuJ0;4:FiBfvPC4zFUk6qMuOECcNi05OLAorc+DhIVJxlNWIywzlftuqZF5sMdCa/Wh472FLnz8wOvAXMdOMlYHQfa5CMm5Cdc/OzLA+yn3qP8VL7STQEwrggaU/oHH2/PjDwzOtoAey+PXn+UkI47/4S2C4bOa4lLON5gvUoCvNyC3OOm3xxv4W3muF1483GH5qrir/R8jj+bT/8HO5jr+SqDkIbDgF5FUpLDouTgVyZaY/P9bszaaS1Vt70J+iYRsts20PPJUDgDTN fohKNXpj5M1CE0eoL1t1/y92hATVy+SWIi5lv7V+e0QkyloUOIlcgIB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016);SRVR:AM0PR08MB3252;BCL:0;PCL:0;RULEID:;SRVR:AM0PR08MB3252; X-Forefront-PRVS: 06891E23FB X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(39380400002)(376002)(346002)(366004)(39850400004)(396003)(189003)(199004)(3846002)(1076002)(6116002)(55016002)(956004)(23686003)(68736007)(476003)(446003)(386003)(6506007)(37156001)(25786009)(6306002)(59450400001)(6246003)(229853002)(316002)(6666003)(2906002)(33656002)(76176011)(58126008)(66066001)(16586007)(6916009)(5660300001)(11346002)(52116002)(186003)(106356001)(47776003)(50466002)(53416004)(8936002)(86362001)(81156014)(8676002)(105586002)(69596002)(97736004)(53936002)(4326008)(486006)(81166006)(26005)(16526019)(9686003)(305945005)(7736002)(478600001)(7696005)(18370500001)(562404015);DIR:OUT;SFP:1102;SCL:1;SRVR:AM0PR08MB3252;H:outlook.office365.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:3;A:1; Received-SPF: None (protection.outlook.com: virtuozzo.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?koi8-r?Q?1;AM0PR08MB3252;23:k6dVHvWZ8OjoWOZazjxmqL26xtIpzjQcwTM9dh+anjv?= =?koi8-r?Q?WpWFZrWVmkNGAJALcDRCCEwUUGR+0H5+6eKPnn/2B8FKt7F6OP3HUGqnqAakOo?= =?koi8-r?Q?mPXE9WOsvI/2f/fliE/WhsunUs4rFmpacrE4o8WM2gLPVgs9q48dSv+5hujPd/?= =?koi8-r?Q?6FSDF/YRPk7fJmQr2OkEdL4EmkZLjY5X6f3JYjVEkA8rF5Zg4+ld45MzmVP5+l?= =?koi8-r?Q?XUekwrtt+sitfwdHs7DCIG70bh1YE8D126UMd1iMj63/1bjgwmUMF+ZKw1Vt+f?= =?koi8-r?Q?S+njfiXowa0+sKcRWv0zUfa3aErTq8PswHL5ktMw7uAGT3H971WIA1xII+BlXU?= =?koi8-r?Q?8Dp2R9tbXYyMZ7T3i+LO/2a/cILgQNHSZZ7wNeXBQqTPhVidX2M4LmODE6yYra?= =?koi8-r?Q?2jpucyL2HpOlzt+x1KcW03Wul9R6Sb2GEZrYihnfhRzwYwe553pGfYTSOgws1D?= =?koi8-r?Q?IeoXxxhX3Bzt03dXyBgBLMQDrBAVEZf4h1n/PO/BDqQgnwScxJ2BklfOnAQkt3?= =?koi8-r?Q?ZFdNVkX+vXO62gtE5OoNyg0kf5b10+lWyczAEO0evCzQfw+VGMM+B5fkYmc1yp?= =?koi8-r?Q?FYP56W/Xg8iK7cf7h6FeF9WI2zEkhcFsnwSANV1s835MOYIGEIVURqZL28WqFX?= =?koi8-r?Q?1t9miXEo X-Microsoft-Antispam-Message-Info: A85HDvspNj/n5GKTxyxIftpVi2/mmxYfMseMXyLdUbL2M0h0iHL1FL6oz1XW9tVpqfKSjaf7txS/8uDubVrwbarxgdlWUji62ycgpWTtSmAzEl6XyZ8YGybefYoZ+OHMRpa31EMSfsTK6OG4BYC2sbte44GgxCFpWsdK3e4GjakXJBwoN2STWou50hL+Cr7N X-Microsoft-Exchange-Diagnostics: 1;AM0PR08MB3252;6:E50njqvQiGaAKN+sNUHMiC+6LQ+jOVyPDQjG6npO/ULrwaSfKhibeWNwSCcRlbX48X6f3jAJcuDKfHiodvxPpuVxgh6e1gF61ZV1NrISRyIwnA0aEkQqMIYSo35oTLspDjDukIUR+mYvg4C0e+5kqdKt3NZGNf2MCzqKs1f7OVMDJS9+YX/Pd8Hsv55N0BKuGZ6UcC97uEDmO8F/YQ9bqzD0iue1IlOXCBj3v0hf2uRAnjnV5BRsenNYzY/CqgF5KRJolxnIfyEEQpZgCVh6R4t+tljNwrkUWiGjpWBM3urVHvTm/ZXLjZSSe5t85PJA17SQf8J1l0ON8XarBboLr4BK54tfWIlaIQDwpYY58CVg11Al+sXUslrktid7qne0eje7JKNg3h5rsKaoDdiKfqCHhz/zlDqx7FpLp5UBxW6b8VLd4pXTp7fhCyqJU91u+RKQJgZwKkvr6YghLUFKhA==;5:33R1/Lw2EjdwQbNA5VeILrt6W/Q/YpN5hhoMSrAjb7WRMNIe/Hk0EEqqE0Pnfsh8P7SU04UN29DYdUJkPFxkoq8VlcQrh0hsrimf0Vhj2S+XcVMl8AIcZ9r5QhBFNF022a/O/hlRcu3Alt3mc6/NCu8/8p2hpmKqe/EAvTZojKc=;24:uv/NUKD/zubMwhQNIj9pMmvhW364FpL8QTQZ3GuFKVe+SsMS4v4vZB3q0KCio52lwmm5gmMpyfA0vX8D7at1CNUV9Ysgmntws0zceE/1etw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM0PR08MB3252;7:JXMASHRj1Qrpbh6UjdLIFAW5fOXXQDs9eazW3RW0TlvqYEwaR6BVFDe5syrfbjzLQH5Cw8vmcEnFf5/WiThiLc+QmTQ4dzN6iI7Bx4LeFr/Gl6ty/yHRC1innBXM1z63H/pAf/XYef6pZXrPbR5Ambg6qsRjDhr0cyq4UcQLqR1Ltdvsh0vjZCzT1X6YVuqjWZgFs9EykNksyb4GNsUbuth5DiH7kSygMKQ4QJQYNR3W3Jomu46+AkxFsRaA7hPi;20:Fy4HA12mT1AiZJZpzMMikoRwoDxZPmxx8wZaRn7vTAHtIXJwv2ALbsWmF7zKLxfXqAvIhJ6SZbtCY2HI7BHqHZmQrB7A8eRihqR8Canu91tet/+24iy+K9I1eL15PW0/H6iC9aIrwnWxkxsEjd3ovLBhPlNIqM8N5eLAdLQPXTw= X-MS-Office365-Filtering-Correlation-Id: 04a92ca5-8fdc-4979-137b-08d5c73c75b4 X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2018 21:21:22.1525 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 04a92ca5-8fdc-4979-137b-08d5c73c75b4 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3252 Xref: news.gmane.org gmane.linux.lib.musl.general:12867 Archived-At: On Thu, May 31, 2018 at 10:44:42PM +0200, Natanael Copa wrote: > On Thu, 31 May 2018 12:00:22 -0700 > Andrei Vagin wrote: > > > >>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. > > That sounds like a bug in musl libc. > > > 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. > > FreeBSD man page says: > > L Indicates that the conversion will be one of a, e, f, or g and > the next pointer is a pointer to long double. > > NetBSD man page says: > > L Indicates that the conversion will be efg and the next pointer is > a pointer to long double. > > OpenBSD man page says: > > L > Indicates that the conversion will be one of efg and the next pointer is a pointer to long double. I have shown the quote from the scanf man page of Alpine Linux, which is based on musl-libc. > > So the application will break on most (every) system that is not GNU > libc. It would be better to fix the application in this case: In our days, a lot of applications are tested only for Linux. In many cases, they probably can work on any unix system too, but they are not tested and in many cases this means that they don't work there. > > > char str[] = "sigmask: 0x200"; > long long mask = 0; > int ret; > > #if defined(__GLIBC__) > ret = sscanf(str, "sigmask: %Lx", &mask)); > #else > ret = sscanf(str, "sigmask: %llx", &mask)); > #endif > printf("%d %llx\n", ret, mask); > > > > Or just use %llx which is POSIX and should work everywhere. Yes, yes, yes. But I spent about an hour to understand why my application works incorrectly. There is another thing, that fprintf(stderr, "smth smth %Lx\n") doesn't work too, so I saw nothing wrong in a log file. > > That said, those things are tricky to detect at compile time as you > mentioned and they are tricky to detect with configure scripts that > works with cross compilation. Also many developers seems to think that > Linux == glibc so they only read the GNU manuals, so yeah, implement > glibc behavior here seems like a good idea, unless someone else has a > brilliant idea how to catch this at compile time. +1 > > In any case, I think the application should be fixed too. Sure, I already sent a patch. I just want to prevent my situation for other users. I like musl-libc, and I think the user experience will be better if it will have fewer cases when applications work with glibc and don't work with musl. I'm a developer of the CRIU project and our experience shows that there is a dozen of issues which has to be fixed to support musl. I don't think that we are so unprofessional and others don't have similar problems;). Thanks, Andrei > > -nc