svn commit: r293792 - head/sys/boot/uboot/lib

[Bruce Evans]

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