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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "[email protected]"
