Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 May 2012 17:51:53 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        svn-src-head@freebsd.org, Xin LI <delphij@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>
Subject:   Re: svn commit: r235852 - head/sys/geom
Message-ID:  <20120524174234.O1352@besplex.bde.org>
In-Reply-To: <4FBD4124.5030205@FreeBSD.org>
References:  <201205231817.q4NIH2t7088267@svn.freebsd.org> <20120523192232.GA1399@garage.freebsd.pl> <4FBD4124.5030205@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 May 2012, Andriy Gapon wrote:

> on 23/05/2012 22:22 Pawel Jakub Dawidek said the following:
>> On Wed, May 23, 2012 at 06:17:02PM +0000, Xin LI wrote:
>>> Author: delphij Date: Wed May 23 18:17:02 2012 New Revision: 235852 URL:
>>> http://svn.freebsd.org/changeset/base/235852
>>>
>>> Log: Use %ju to match uintmax_t usage
>>>
>>> Modified: head/sys/geom/geom_flashmap.c
>>>
>>> Modified: head/sys/geom/geom_flashmap.c
>>> ==============================================================================
>>>
>>>
> --- head/sys/geom/geom_flashmap.c	Wed May 23 18:11:36 2012	(r235851)
>>> +++ head/sys/geom/geom_flashmap.c	Wed May 23 18:17:02 2012	(r235852) @@
>>> -78,7 +78,7 @@ static void g_flashmap_print(struct g_flashmap_slice
>>> *slice) {
>>>
>>> -	printf("%08jx-%08jx: %s (%lluKB)\n", (intmax_t)slice->sl_start,
>>> (intmax_t)slice->sl_end, +	printf("%08jx-%08jx: %s (%juKB)\n",
>>> (intmax_t)slice->sl_start, (intmax_t)slice->sl_end, slice->sl_name,
>>> (uintmax_t)(slice->sl_end - slice->sl_start) / 1024);
>>
>> BTW, %jx is also uintmax_t, not intmax_t, right?
>
> I think that non-decimal representation generally implies unsigned-ness.

But it is another bug.  I already pointed this out. but didn't notice
then that it took 3-4 commits to get this far.

Sometimes negative values need to be printed in hex, with the burden of
interpreting the sign bit left to the user.  Then the correct cast to
use is problematic -- if you actually want to see the bits, then you
don't want casting to change them, but perhaps it does change them for
the 1's complement and other exotic cases.  So hex printing of negative
values probably shouldn't use casts at all, but should point at the
object using u_char * and print the bits 1 byte at a time.

These complications probably don't apply here.  Probably the values are
always nonnegative, so they can be printed in hex by simply casting them,
and the casts should be to an unsigned type to match the format.  The hex
format is just bad here, with 2 or 3 internal bugs starting with it never
having an 0x prefix -- see a previous reply.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120524174234.O1352>