Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Dec 2016 21:30:42 -0500
From: Rich Felker <>
Subject: Re: Handling of L and ll prefixes different from glibc

On Wed, Dec 14, 2016 at 04:37:55PM -0600, A. Wilcox wrote:
> Hash: SHA256
> On 14/12/16 11:17, Szabolcs Nagy wrote:
> > * Rich Felker <> [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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.