Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jun 2011 08:23:53 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw>, src-committers@freebsd.org
Subject:   Re: svn commit: r223139 - head/lib/libstand
Message-ID:  <BANLkTinNn_74N4Zp%2BjWPq%2Bh9ue6uDMMyRg@mail.gmail.com>
In-Reply-To: <BANLkTinpp95JyEp8sVR7uL-sAWor-69mCA@mail.gmail.com>
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> <20110616235239.D1926@besplex.bde.org> <BANLkTinpp95JyEp8sVR7uL-sAWor-69mCA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--0022154700ae58cacb04a5d5dba8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 8:12 AM, Garrett Cooper <yanegomi@gmail.com> wrote:
> On Thu, Jun 16, 2011 at 7:06 AM, Bruce Evans <brde@optusnet.com.au> wrote=
:
>> 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. =A0stand.h doesn't use anything in
>>>> <stdint.h>. =A0It depends on normal namespace pollution in an XXX sect=
ion
>>>> in <sys/types.h> for the declaration of uintptr_t. =A0It and other hea=
ders
>>>> should use __uintptr_t instead. =A0Strangely, <sys/types.h> declares
>>>> uintptr_t but not uintmax_t.
>>>
>>> =A0What about casting to __uintmax_t instead?
>>>
>>> Index: zalloc.c
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> --- zalloc.c =A0 =A0(revision 223146)
>>> +++ zalloc.c =A0 =A0(working copy)
>>> @@ -154,7 +154,7 @@
>>> =A0 =A0if ((char *)ptr < (char *)mp->mp_Base ||
>>> =A0 =A0 =A0 =A0(char *)ptr + bytes > (char *)mp->mp_End ||
>>> =A0 =A0 =A0 =A0((iaddr_t)ptr & MEMNODE_SIZE_MASK) !=3D 0)
>>> - =A0 =A0 =A0 panic("zfree(%p,%ju): wild pointer", ptr, bytes);
>>> + =A0 =A0 =A0 panic("zfree(%p,%ju): wild pointer", ptr, (__uintmax_t)by=
tes);
>>> ...
>>
>> 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. =A0For amd6=
4
>> 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. =A0I would expect all 64-b=
it
>> arches to do this, although this is logically wrong (it makes the larges=
t
>> integral type uintmax_t logically smaller than the standard bogus type
>> unsigned long long). =A0This logic error is partly intentional (it detec=
ts
>> different type mismatches than uintmax_t =3D `unsigned long long' combin=
ed
>> with uint64_t =3D `unsigned long' would).
>
> =A0 =A0My second patch when applied gets one past tinderbox on powerpc..
> waiting for powerpc64 and sparc64 to complete. Namespace pollution is
> one thing, but stdint.h isn't that bad IMHO -- I just find it funny
> that iaddr_t had to be typedef'ed to uintptr_t in the first place.

This needs to be committed to unbreak ia64 and mips64*. Still waiting
to see what happens with sparc64, but amd64 and powerpc64 were oddly
happy without this, even though they should have failed along with
ia64 and mips64* (the format string should have been %zu for a size_t
type).

Will rerun universe once it completes on amd64, ia64 and sparc64
though later on today..
Thanks!
-Garrett

--0022154700ae58cacb04a5d5dba8
Content-Type: text/x-patch; charset=US-ASCII; 
	name="fix-libstand-zalloc_malloc-ia64+mips64.patch"
Content-Disposition: attachment; 
	filename="fix-libstand-zalloc_malloc-ia64+mips64.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gozuw1d90

SW5kZXg6IGxpYi9saWJzdGFuZC96YWxsb2NfbWFsbG9jLmMKPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbGliL2xp
YnN0YW5kL3phbGxvY19tYWxsb2MuYwkocmV2aXNpb24gMjIzMTQwKQorKysgbGliL2xpYnN0YW5k
L3phbGxvY19tYWxsb2MuYwkod29ya2luZyBjb3B5KQpAQCAtMTEwLDcgKzExMCw3IEBACiAJICAg
IHJldHVybjsKIAl9CiAJaWYgKCooKHNpZ25lZCBjaGFyICopcmVzICsgcmVzLT5nYV9CeXRlcyAt
IDEpICE9IC0yKQotCSAgICBwYW5pYygiZnJlZTogZ3VhcmQyIGZhaWwgQCAlcCArICVkIGZyb20g
JXM6JWQiLCBwdHIsIHJlcy0+Z2FfQnl0ZXMgLSBNQUxMT0NBTElHTiwgZmlsZSwgbGluZSk7CisJ
ICAgIHBhbmljKCJmcmVlOiBndWFyZDIgZmFpbCBAICVwICsgJXp1IGZyb20gJXM6JWQiLCBwdHIs
IHJlcy0+Z2FfQnl0ZXMgLSBNQUxMT0NBTElHTiwgZmlsZSwgbGluZSk7CiAJKigoc2lnbmVkIGNo
YXIgKilyZXMgKyByZXMtPmdhX0J5dGVzIC0gMSkgPSAtMTsKICNlbmRpZgogCg==
--0022154700ae58cacb04a5d5dba8--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinNn_74N4Zp%2BjWPq%2Bh9ue6uDMMyRg>