On Friday, December 16, 2016 04:53:04 PM Eric van Gyzen wrote:
> 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 <b...@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.
Hmm, that might work, but it is still cumbersome. Probably to make things
readable
we'd end up with a wrapper:
printb(uint val, const char *fmt)
{
char buf[strlen(fmt) + C];
snprintb(...);
printf("%s", buf);
}
--
John Baldwin
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
