On 16 Dec 2016, at 19:31, Baptiste Daroussin <b...@freebsd.org> wrote: > > Other than that, it makes more difficult to use vanilla gcc with out userland. > and it is adding more complexity to be able to build freebsd from a non > freebsd > system which some people are working on.
Why? You’ll get some spurious warnings about printf, but that’s all. Our printf (like the glibc one) already supports user-defined extensions via register_printf_function (for which, I note, we don’t have a man page), so third-party code also has some of these warnings if they’ve registered other printf handlers. I’d actually consider that to be the biggest argument against adding %b support: we support users adding their own interpretation of %b via register_printf_function and this will break anyone third-party code where people do this. This commit is doubly bad, because not only does it change our ABI, it doesn’t document the fact. The code in this commit is also simply broken. It does not add a corresponding handler in xprintf.c, so as soon as someone calls register_printf_function with *any* argument, printf’s ability to handle %b will be broken in a difficult-to-debug way. David
smime.p7s
Description: S/MIME cryptographic signature
