From owner-svn-src-head@FreeBSD.ORG Tue Nov 5 01:33:38 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7061843; Tue, 5 Nov 2013 01:33:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 5E86521D5; Tue, 5 Nov 2013 01:33:37 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 3C5F9D62054; Tue, 5 Nov 2013 12:33:29 +1100 (EST) Date: Tue, 5 Nov 2013 12:33:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Sean Bruno Subject: Re: svn commit: r257638 - head/cddl/contrib/opensolaris/lib/libnvpair In-Reply-To: <201311041615.rA4GFhW9040552@svn.freebsd.org> Message-ID: <20131105114408.B2099@besplex.bde.org> References: <201311041615.rA4GFhW9040552@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=6fV5gcbYauMA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=S8UvTrfacXEA:10 a=8U5LxAoS-j-SA4MXKO4A:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 05 Nov 2013 01:33:39 -0000 On Mon, 4 Nov 2013, Sean Bruno wrote: > Log: > Quiesce warning regarding %llf which has no effect. > > Submitted as illumos issue #4284 > > Reviewed by: delphij > > Modified: > head/cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c > > Modified: head/cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c > ============================================================================== > --- head/cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c Mon Nov 4 15:55:04 2013 (r257637) > +++ head/cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c Mon Nov 4 16:15:43 2013 (r257638) > @@ -210,7 +210,7 @@ NVLIST_PRTFUNC(int32, int32_t, int32_t, > NVLIST_PRTFUNC(uint32, uint32_t, uint32_t, "0x%x") > NVLIST_PRTFUNC(int64, int64_t, longlong_t, "%lld") > NVLIST_PRTFUNC(uint64, uint64_t, u_longlong_t, "0x%llx") > -NVLIST_PRTFUNC(double, double, double, "0x%llf") > +NVLIST_PRTFUNC(double, double, double, "0x%f") > NVLIST_PRTFUNC(string, char *, char *, "%s") > NVLIST_PRTFUNC(hrtime, hrtime_t, hrtime_t, "0x%llx") This still has an obfuscating 0x prefix for floating point. This still has the following printf format errors and style bugs: - wrong ptype for vtype uint32_t. The ptype uint32_t is only accidentally compatible with %x. Depending on it being the same bogotifies the careful design of the API -- ptype exists to convert vtype to exactly the type of the format specifier. - use of explicit "0x" prefix for hex numbers. The "#" flag does this better - use of the long long abomination. Assumptions in this use. The longlong_t typedef exists to hide the unportabilities of the abomination. It is semi-opaque and might not be exactly long long. It is for the ptype when the format is "%lld". The latter uses precisely long long, so there is a type mismatch if and only if the longlong_t type is needed as a typedef. Also, if long long has to be typedefed because it doesn't exist, then "%lld" probably doesn't exist either. I think longlong_t is always long long in cddl, so this is only an obfuscation. It is declared in a cddl header in /sys/. In /sys/, the long long abomination is too often used, although I terminated most uses of it before it was standardized, but outside of cddl, longlong_t is only used in a couple of places in xdr/xdr.c. xdr.c declares it as quad_t, so it differs from long long on 64-bit arches. rpc/xdr.h uses quad_t directly. The correct format for printing int64_t is "%jd" and the correct ptype for that is intmax_t. libvnpair doesn't even support printing the long long type abomination -- it only uses it cast to match the format, and never starts with a long long. - similarly for the unsigned long long abomination. - wrong ptype for vtype hrtime_t. The ptype is the same as the vtype. This assumes that hrtime_t is unsigned long long to work with format "%llx". It is actually signed long long. As above, ptype exists to avoid making such assumptions. - the sign mismatches for hrtime_t might be more than style bugs. Hex isn't a very good format for times. Hex formats are always unsigned, and if hrtime_t actually needs to be signed then it can hold negative values and these should not be printed as raw hex. Bruce