On Fri, Dec 16, 2016 at 3:07 PM, John Baldwin <j...@freebsd.org> wrote: > 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); > }
Sadly this "cure" is worse than the disease. Warner _______________________________________________ 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"
