Date: Wed, 13 Jan 2016 15:03:07 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <ian@freebsd.org> 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 Message-ID: <20160113142527.U1277@besplex.bde.org> In-Reply-To: <201601130022.u0D0MCWu029299@repo.freebsd.org> References: <201601130022.u0D0MCWu029299@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <machine/profile.h> 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 <machine/profile.h>: 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 <machine/profile.h> but a fixed-width type in <machine/_types.h>. arm64 uses the long long abomination to get a type mismatch (same width, higher rank) in <machine/profile.h>. This was consistent in FreeBSD-4 where __uintfptr_t doesn't exist. uintptr_t was only declared in <machine/profile> (and <sys/gmon.h> via intentional pollution) so there was no difference for the kernel to confuse you. But <sys/gmon.h> must be included. <sys/gmon.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160113142527.U1277>