From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12871 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [PATCH] scanf: handle the L modifier for integers Date: Fri, 1 Jun 2018 02:30:50 +0200 Message-ID: <20180601003050.GM4418@port70.net> References: <20180531064719.6805-1-avagin@virtuozzo.com> <20180531190021.GA9758@outlook.office365.com> <20180531224442.3bc8dcdc@ncopa-desktop.copa.dup.pw> <20180531234436.GN1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1527812938 23007 195.159.176.226 (1 Jun 2018 00:28:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2018 00:28:58 +0000 (UTC) User-Agent: Mutt/1.9.1 (2017-09-22) To: musl@lists.openwall.com Original-X-From: musl-return-12887-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 01 02:28:54 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 1fOXw5-0005tT-PX for gllmg-musl@m.gmane.org; Fri, 01 Jun 2018 02:28:53 +0200 Original-Received: (qmail 7891 invoked by uid 550); 1 Jun 2018 00:31:02 -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 7870 invoked from network); 1 Jun 2018 00:31:02 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20180531234436.GN1392@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12871 Archived-At: * Rich Felker [2018-05-31 19:44:36 -0400]: > On Thu, May 31, 2018 at 10:44:42PM +0200, Natanael Copa wrote: > > 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. > > Aside from fixing gcc at compile time, this has come up before (with > regard to printf, not scanf), and my leaning then and now was to > detect the UB at runtime by crashing rather than reporting an error as > we do now, since (1) it's UB, so an application can't reasonably > expect an error, and (2) applications seem to be ignoring errors > anyway. > > We should also get the man page fixed. The printf man page is clear > that L with integer specifiers is a nonstandard extension and should > not be used (they're not documented under L, only as a note at the > end) but it seems whoever fixed this overlooked changing scanf at the > same time. > also note that adding extensions to printf this way can break forward compatibility, because the standard can introduce %Ld with a different meaning, this happend before: in glibc scanf %a was used for 'allocation modifier' then later iso c introduced it for hex floats, now scanf behaves differently based on CFLAGS (standard conform mode uses different scanf), this involves hacks in glibc which nobody wants to repeat so nowadays new extensions are only added once they are expected to be standardized. (if musl aimed for full glibc compatibility then it would have to copy the messy %a behaviour too, fortunately that's not in widespread use just like the %Ld extension..)