From owner-svn-src-head@freebsd.org Sat Dec 17 08:52:24 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 9C94FC82522; Sat, 17 Dec 2016 08:52:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3052A66A; Sat, 17 Dec 2016 08:52:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id a20so9464747wme.2; Sat, 17 Dec 2016 00:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ICfjKf/d+wmTcHiLs8VrOOFS5YzdgTcs8vM4jIJV7lk=; b=XI76KSFrNAPPIjthtIcXazLp/Z5Fuhs3r3flK/xo+R3LJkWt7G6deaHWcIyWQ5wFBX cQR1gZuqP1ogW5WMTt8gVvdjU0hZ0TggG4QzGoZjdIJZqJVNOYbd0KuLD2fDN6j87S9E HOZep9FR4xp8aRuVexX7MTJcq6GEbfN6aCGLEENlTDiL6CjA6oX6EmM4jut3Gn1kz4Xa a/CVBQqQZOM1tpbfxbb35tewiAFFjpXSuMqvzwlY1YlvIG9VVAUU53LGjj9ec27UFi0A KksDVtpTkcZqUZtt7Cevo2io4UPyvmQYjw+cKdy37HzjgX1CRud/git74wLpJTaz4YJj tpCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ICfjKf/d+wmTcHiLs8VrOOFS5YzdgTcs8vM4jIJV7lk=; b=MSQX4mQGbE+TjV/bgERk3x0wvmIbXYNsXD2Dj1tn93ZMAzXFr2RDR4/PbXKjbBKXrJ +aOFz7Vl2boKaSVp1rqof/gcL9ECQbFrbvnJs3n9qkuLJU7dWZuM12Sf7rA0vfGOmeEi uftoFSvar6Q21cgKopZQquNOHarpuUnYRh72qLsaeWNwJ6Shdp5kzyATifF+DfIiEO/b wovfl1r84lGo6lru8kFRV8J1IrZ/xvaGtEjRw6HMaBysMsY5eyPW9ONFjsP+bygaMKcG U6zkYxOqfr/R2vUHygGyAfgjjzsJ4Y7RGyVWOSjU0PFUAcBA9fI+qF/0xW+zA38JbBc8 HsJQ== X-Gm-Message-State: AIkVDXJsWnTcUKf+LBd9/VgsGjmVRiLC57u14AKpCnY0Bu30I8ra37DSNOomvWTDnvpoLTveEHQKzMIGg+Vaeg== X-Received: by 10.28.139.131 with SMTP id n125mr6283792wmd.116.1481964742079; Sat, 17 Dec 2016 00:52:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.1 with HTTP; Sat, 17 Dec 2016 00:52:21 -0800 (PST) In-Reply-To: References: <201612160144.uBG1ipjW016736@repo.freebsd.org> <13059937.h5mayX8aKo@ralph.baldwin.cx> <9e255301-f663-a96c-68c7-e6d1a3d1db8c@FreeBSD.org> <3160837.brVkGGj5yS@ralph.baldwin.cx> From: Adrian Chadd Date: Sat, 17 Dec 2016 00:52:21 -0800 Message-ID: Subject: Re: svn commit: r310138 - head/lib/libc/stdio To: Eric van Gyzen Cc: Warner Losh , John Baldwin , Dimitry Andric , Baptiste Daroussin , "Conrad E. Meyer" , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Sat, 17 Dec 2016 08:52:24 -0000 ... just have printf_freebsd in libutil; have it know about our extended fmt types. then we just have to port libutil to a target platform. -a On 16 December 2016 at 17:31, Eric van Gyzen wrote: > On 12/16/2016 17:44, Warner Losh wrote: >> On Fri, Dec 16, 2016 at 3:07 PM, John Baldwin 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 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. > > How about this cure? > > printf("reg=%b\n", value, FORMAT); > > // versus > > char buf[BITMASK_BUFFER_SIZE(FORMAT)]; > printf("reg=%s\n", format_bitmask(buf, sizeof(buf), value, FORMAT)); > > That doesn't seem so bad. > > Eric >