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

[Eric van Gyzen]

On 12/16/2016 16:45, John Baldwin wrote:
> On Friday, December 16, 2016 08:53:26 PM Dimitry Andric wrote:
>> On 16 Dec 2016, at 20:31, Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>>>
>>> On Fri, Dec 16, 2016 at 01:44:51AM +0000, Conrad E. Meyer wrote:
>>>> Author: cem
>>>> Date: Fri Dec 16 01:44:50 2016
>>>> New Revision: 310138
>>>> URL: https://svnweb.freebsd.org/changeset/base/310138
>>>>
>>>> Log:
>>>>  vfprintf(3): Add support for kernel %b format
>>>>
>>>>  This is a direct port of the kernel %b format.
>>>>
>>>>  I'm unclear on if (more) non-portable printf extensions will be a
>>>>  problem. I think it's desirable to have userspace formats include all
>>>>  kernel formats, but there may be competing goals I'm not aware of.
>>>>
>>>>  Reviewed by:	no one, unfortunately
>>>>  Sponsored by:	Dell EMC Isilon
>>>>  Differential Revision:	https://reviews.freebsd.org/D8426
>>>>
>>>
>>> I really don't think it is a good idea, if used in userland it would be make
>>> more of our code difficult to port elsewhere.
>>
>> Indeed, this is a bad idea.  These custom format specifiers should be
>> eliminated, not multiplied. :-)
>>
>>
>>> 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.
>>>
>>> Personnaly I would prefer to see those extensions removed from the kernel rather
>>> than see them available in userland.
>>
>> Same here.
>>
>>
>>> Can't we use simple helper function instead?
>>
>> Yes, please.  Just take the snprintb(3) function from NetBSD:
>>
>> http://netbsd.gw.com/cgi-bin/man-cgi?snprintb+3+NetBSD-current
> 
> In general I agree with something like this instead, but it is quite a bit more
> tedious to use as you have to run it once to determine the length, allocate a
> buffer, and then run it again.  Calling malloc() for that buffer isn't always
> convenient in the kernel (though it should be fine in userland).  Having it live
> in printf() itself means the output is generated to the stream without having to
> manage a variable-sized intermediate buffer.

I imagine most callers can simply use a char[sizeof(fmt)+C] on the stack, where
C is some constant that I haven't taken the time to calculate, at the risk of
making myself look foolish and unprofessional.

Eric