mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Handling of L and ll prefixes different from glibc
Date: Wed, 14 Dec 2016 21:30:42 -0500	[thread overview]
Message-ID: <20161215023042.GW1555@brightrain.aerifal.cx> (raw)
In-Reply-To: <5851C9C3.6050609@adelielinux.org>

On Wed, Dec 14, 2016 at 04:37:55PM -0600, A. Wilcox wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 14/12/16 11:17, Szabolcs Nagy wrote:
> > * Rich Felker <dalias@libc.org> [2016-12-14 11:13:48 -0500]:
> >> behavior. I'm mildly leaning towards causing a crash on invalid
> >> format strings so that the location of the incorrect usage can be
> >> quickly found with a debugger, but I'd like feedback from users
> >> who've debugged this sort of thing on whether that'd actually be
> >> helpful.
> > 
> > crashing sounds good to me.
> > 
> 
> Would this be able to be configured in some way when building the libc
> (-D_CRASH_ON_PRINTF_UB or such)?
> 
> This sounds like a great tool to use when doing conformance testing,
> and in general once testing has been done.  However, it also sounds
> like a great way to break packages already "working" on musl.

While that's possible, I _really_ prefer avoiding switches like this.
It's a path that leads to maintenance-death of a project.

It's true that some programs which are just misusing printf format
specifiers as part of unnecessary status/debug/junk output will fully
work now, despite having UB, and that they would stop working with
such a change. But in most cases, the lack of output now, even if it's
unnoticed, is a bug that could have serious consequences. For example
missing output in text that's parsed and used in a script can lead to
things like rm -rf'ing the wrong directory. So I tend to think always
failing hard and catching the bug is preferable.

BTW I wonder if gcc's -Wformat catches these errors.

Rich


  reply	other threads:[~2016-12-15  2:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-14 13:46 Nadav Har'El
2016-12-14 16:13 ` Rich Felker
2016-12-14 17:17   ` Szabolcs Nagy
2016-12-14 22:37     ` A. Wilcox
2016-12-15  2:30       ` Rich Felker [this message]
2016-12-15  4:01         ` A. Wilcox
2016-12-15 11:30           ` Szabolcs Nagy

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=20161215023042.GW1555@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).