Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jun 2011 00:06:43 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw>
Cc:        Garrett Cooper <yanegomi@gmail.com>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: svn commit: r223139 - head/lib/libstand
Message-ID:  <20110616235239.D1926@besplex.bde.org>
In-Reply-To: <11061619555315.44181@www.mmlab.cse.yzu.edu.tw>
References:  <201106160714.p5G7Etfx017112@svn.freebsd.org> <BANLkTi=X0_SBLAQ6t7amTLv7jF6_oXAV4Q@mail.gmail.com> <BANLkTimG4svFzv1QPiKQcC7QdChLica9xA@mail.gmail.com> <20110616180803.D1005@besplex.bde.org> <11061619555315.44181@www.mmlab.cse.yzu.edu.tw>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Jun 2011, Tai-hwa Liang wrote:

> On Thu, 16 Jun 2011, Bruce Evans wrote:
>
>> On Thu, 16 Jun 2011, Garrett Cooper wrote:
>>>
>>> And you need to add #include <stdint.h> to stand.h in order to get
>>> uintmax_t. Here's a proper patch for amd64..
>> 
>> This would add namespace pollution.  stand.h doesn't use anything in
>> <stdint.h>.  It depends on normal namespace pollution in an XXX section
>> in <sys/types.h> for the declaration of uintptr_t.  It and other headers
>> should use __uintptr_t instead.  Strangely, <sys/types.h> declares
>> uintptr_t but not uintmax_t.
>
>  What about casting to __uintmax_t instead?
>
> Index: zalloc.c
> ===================================================================
> --- zalloc.c	(revision 223146)
> +++ zalloc.c	(working copy)
> @@ -154,7 +154,7 @@
>     if ((char *)ptr < (char *)mp->mp_Base ||
> 	(char *)ptr + bytes > (char *)mp->mp_End ||
> 	((iaddr_t)ptr & MEMNODE_SIZE_MASK) != 0)
> -	panic("zfree(%p,%ju): wild pointer", ptr, bytes);
> +	panic("zfree(%p,%ju): wild pointer", ptr, (__uintmax_t)bytes);
> ...

zalloc.c is not the (header) implementation, so it should not use the
implementation detail (anything beginning with __).

The latest tinderbox errors for this are hard to understand.  For amd64
they say:

> /src/lib/libstand/zalloc.c: In function 'zfree':
> /src/lib/libstand/zalloc.c:157: warning: format '%ju' expects type 'uintmax_t', but argument 3 has type 'iaddr_t'

but amd64 seems to be just like sparc64 -- both seem to declare all the
types as `unsigned long' at the lowest level.  I would expect all 64-bit
arches to do this, although this is logically wrong (it makes the largest
integral type uintmax_t logically smaller than the standard bogus type
unsigned long long).  This logic error is partly intentional (it detects
different type mismatches than uintmax_t = `unsigned long long' combined
with uint64_t = `unsigned long' would).

Bruce



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