From owner-svn-src-head@freebsd.org Fri Dec 16 23:19:14 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35548C83FBD; Fri, 16 Dec 2016 23:19:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12FF418AC; Fri, 16 Dec 2016 23:19:14 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 15F8010AA2C; Fri, 16 Dec 2016 18:19:13 -0500 (EST) From: John Baldwin To: Eric van Gyzen Cc: Dimitry Andric , Baptiste Daroussin , "Conrad E. Meyer" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r310138 - head/lib/libc/stdio Date: Fri, 16 Dec 2016 15:07:25 -0800 Message-ID: <3160837.brVkGGj5yS@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) In-Reply-To: <9e255301-f663-a96c-68c7-e6d1a3d1db8c@FreeBSD.org> References: <201612160144.uBG1ipjW016736@repo.freebsd.org> <13059937.h5mayX8aKo@ralph.baldwin.cx> <9e255301-f663-a96c-68c7-e6d1a3d1db8c@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 16 Dec 2016 18:19:13 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 23:19:14 -0000 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 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