From owner-svn-src-all@freebsd.org Wed Jan 13 04:03:11 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D31CA801ED; Wed, 13 Jan 2016 04:03:11 +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 07B561E04; Wed, 13 Jan 2016 04:03:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 166A3D63709; Wed, 13 Jan 2016 15:03:08 +1100 (AEDT) Date: Wed, 13 Jan 2016 15:03:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ian Lepore cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r293792 - head/sys/boot/uboot/lib In-Reply-To: <201601130022.u0D0MCWu029299@repo.freebsd.org> Message-ID: <20160113142527.U1277@besplex.bde.org> References: <201601130022.u0D0MCWu029299@repo.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=R4L+YolX c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=JzwRw_2MAAAA:8 a=kj9zAlcOel0A:10 a=e7gxmwbq5dYOh8Y6tOgA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 04:03:11 -0000 On Wed, 13 Jan 2016, Ian Lepore wrote: > Log: > Go back to using uintptr_t, because code that actually compiles is > infinitely less buggy than code that is theoretically correct in some > alternate universe. > > The uintfptr_t type is apparently a freebsd invention, and exists only when > compiling the kernel. It's a little hard to say for sure, since it doesn't > seem to be documented anywhere except in email advice to unsuspecting and > overly-trusting souls, who then get to wear the pointy hat for blindly > following advice without investigating or testing it first. Oops. It is only declared in outside of the kernel. Only __uintfptr_t is always declared by sys/types.h. Grep shows some style bugs (spelling mismatches) for *uintfptr_t in : X amd64/include/profile.h:typedef u_long uintfptr_t; X arm/include/_types.h:typedef __uint32_t __uintfptr_t; X arm/include/profile.h:typedef u_int uintfptr_t; X arm64/include/_types.h:typedef __uint64_t __uintfptr_t; X arm64/include/profile.h:typedef unsigned long long uintfptr_t; X i386/include/profile.h:typedef u_int uintfptr_t; X mips/include/_types.h:typedef __uint64_t __uintfptr_t; X mips/include/_types.h:typedef __uint32_t __uintfptr_t; X mips/include/profile.h:typedef u_long uintfptr_t; X mips/include/profile.h:typedef u_int uintfptr_t; X powerpc/include/_types.h:typedef __uint64_t __uintfptr_t; X powerpc/include/_types.h:typedef __uint32_t __uintfptr_t; X powerpc/include/profile.h:typedef u_long uintfptr_t; X powerpc/include/profile.h:typedef u_int uintfptr_t; X sparc64/include/_types.h:typedef __uint64_t __uintfptr_t; X sparc64/include/profile.h:typedef u_long uintfptr_t; X x86/include/_types.h:typedef __uint64_t __uintfptr_t; X x86/include/_types.h:typedef __uint32_t __uintfptr_t; All except arm64 are consistently inconsistent in using the correct basic type in but a fixed-width type in . arm64 uses the long long abomination to get a type mismatch (same width, higher rank) in . This was consistent in FreeBSD-4 where __uintfptr_t doesn't exist. uintptr_t was only declared in (and via intentional pollution) so there was no difference for the kernel to confuse you. But must be included. has a reference but no useful documentation in moncontrol(3), and a surprisingly large amount of documentation in sysctl(3) of all places. It seems I didn't enlarge this when I enlarged gmon with much more than uintfptr_t. Bruce