svn commit: r293792 - head/sys/boot/uboot/lib
Bruce Evans
brde at optusnet.com.au
Wed Jan 13 04:03:11 UTC 2016
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
More information about the svn-src-all
mailing list