mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Re: [PATCH] scanf: handle the L modifier for integers
Date: Thu, 31 May 2018 20:59:54 -0400	[thread overview]
Message-ID: <20180601005954.GP1392@brightrain.aerifal.cx> (raw)
In-Reply-To: <20180601003050.GM4418@port70.net>

On Fri, Jun 01, 2018 at 02:30:50AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [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.

Yes. Not implementing nonstandard printf extensions was an intentional
choice, the only exception being %m which POSIX already specifies for
syslog(). The %a mess with scanf is a strong motivation for this
choice.

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

musl also has general policy regarding inclusion or exclusion of
nonstandard functionality, and printf/scanf extensions fall pretty
strongly under exclude. They're not widely supported on other
implementations, already have portable alternatives, and have no way
to detect whether they're supported and work or not (since there are
no corresponding macros or configure-time symbol tests you could do to
check for them, and even runtime checks would invoke undefined
behavior.

Rich


  reply	other threads:[~2018-06-01  0:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31  6:47 Andrei Vagin
2018-05-31 14:20 ` Laurent Bercot
2018-05-31 19:00 ` Andrei Vagin
2018-05-31 20:44   ` Natanael Copa
2018-05-31 21:21     ` Andrei Vagin
2018-05-31 23:44     ` Rich Felker
2018-06-01  0:30       ` Szabolcs Nagy
2018-06-01  0:59         ` Rich Felker [this message]
2018-06-01  7:36       ` Andrei Vagin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180601005954.GP1392@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).