svn commit: r310433 - head/lib/libc/stdio

[Ngie Cooper (yaneurabeya)]

> On Dec 22, 2016, at 2:39 PM, Conrad Meyer <cem at freebsd.org> wrote:
> 
> This was unjustified and inappropriate.


Conrad,

	From the committer’s guide ( https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#developer.relations <https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#developer.relations> ):
If you are unsure about a commit for any reason at all, have it reviewed by -hackers before committing. Better to have it flamed then and there rather than when it is part of the repository. If you do happen to commit something which results in controversy erupting, you may also wish to consider backing the change out again until the matter is settled. Remember – with a version control system we can always change it back.

	Per the commit message, the change wasn’t reviewed before commit (" Reviewed by:	no one, unfortunately”). More than a handful of people requested that the commit be reverted/changed. There wasn’t an issue with the content created — there was just an issue with how %b was implemented (especially when it impedes being able to cross-compile FreeBSD on other operating systems or port code to those operating systems).
	Dmitriy’s comment about adding snprintb(3) from NetBSD makes a lot of sense and will reintroduce the code that you added here, and I fully agree and support his suggestion.
	For what it’s worth from personal experience, it’s really a pain when non-standard things get leaked into FreeBSD, or when you have to port software to other operating systems that use non-standard interfaces (I usually have to do this moving Linux code to FreeBSD). Take the format -fformat* string functionality in OneFS — it’s unfortunate that we can’t use a standard compiler to compile OneFS out of the box and instead have to bootstrap a compiler which is intelligent enough to understand how the custom format strings work, just to compile user space/a kernel.
Thank you,
-Ngie