From owner-svn-src-head@FreeBSD.ORG Thu Jun 16 15:12:28 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 032CC106564A; Thu, 16 Jun 2011 15:12:28 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F19B8FC0A; Thu, 16 Jun 2011 15:12:27 +0000 (UTC) Received: by vws18 with SMTP id 18so1756134vws.13 for ; Thu, 16 Jun 2011 08:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PVMj6KjAvYQhaWruv6AeZL8IIXQ95YPtBX/Yui5OUOw=; b=oUIeQEJ7Ps3PBvz5mJ1HAMpLaGHcykdnKjMkVGATgX2kj1tfsGJrdG2hrc0xWhX9hJ 6DQmBw08s5ev++8dFOEuUQ7hEkHy0ZwXMqa6cSixCrcOn+VQX9v3ffY9tVbHjwhHG79U QoedczFK4dnhKpqPYJb2ftjcpxwCq12WW5g/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gGEyXK7vCV3sX4AIUNoMGIaxa+QUZY2dvNvHggRmPprbRh83p+uovd1lrfuY/GScvD BK0eOnVnHtK6rTkUV8iDHL3NFH2/DEb4HAvwtMSNeK4ebr0lv5cmxk4EufKn+KRsYkM4 Oy1aIGiPP7Z8dXFpF0YmZUJPNjD5G0/0KRELM= MIME-Version: 1.0 Received: by 10.220.48.136 with SMTP id r8mr21843vcf.93.1308237146606; Thu, 16 Jun 2011 08:12:26 -0700 (PDT) Received: by 10.220.189.202 with HTTP; Thu, 16 Jun 2011 08:12:26 -0700 (PDT) In-Reply-To: <20110616235239.D1926@besplex.bde.org> References: <201106160714.p5G7Etfx017112@svn.freebsd.org> <20110616180803.D1005@besplex.bde.org> <11061619555315.44181@www.mmlab.cse.yzu.edu.tw> <20110616235239.D1926@besplex.bde.org> Date: Thu, 16 Jun 2011 08:12:26 -0700 Message-ID: From: Garrett Cooper To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Tai-hwa Liang , src-committers@freebsd.org Subject: Re: svn commit: r223139 - head/lib/libstand X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 16 Jun 2011 15:12:28 -0000 On Thu, Jun 16, 2011 at 7:06 AM, Bruce Evans 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 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 >>> . =A0It depends on normal namespace pollution in an XXX secti= on >>> in for the declaration of uintptr_t. =A0It and other head= ers >>> should use __uintptr_t instead. =A0Strangely, 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)byt= es); >> ... > > 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 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. =A0I would expect all 64-bi= t > 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). =A0This logic error is partly intentional (it detect= s > different type mismatches than uintmax_t =3D `unsigned long long' combine= d > with uint64_t =3D `unsigned long' would). My 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. Thanks! -Garrett