On Fri, 13 Nov 2015, David Chisnall wrote:
On 13 Nov 2015, at 08:35, Konstantin Belousov <kostik...@gmail.com> wrote:
On Fri, Nov 13, 2015 at 09:18:54AM +0100, Hans Petter Selasky wrote:
Hi,
On 11/12/15 18:17, Conrad Meyer wrote:
These should cast through (u)intptr_t rather than unsigned long.
This is Linux code, and they use "unsigned long" for pointer casts
everywhere, trying to not break their style.
BTW: I added to linux_compat.c:
CTASSERT(sizeof(unsigned long) == sizeof(uintptr_t));
And it survived my "tinderbox" build and I was surprised!
This is not surprising. "long" is broken on all supported systems
since no 16-bit systems are supported and misimplementations with longs
the same size as int or register_t are not unusable on 32+ bit systems.
Longs should actually be long. That means that they should be longer
than register_t, so they are also longer than pointers except on systems
with large pointers like x86 with far pointers.
FreeBSD (at least currently) runs on two kinds of ABIs: ILP32 and LP64.
ILP32 means that sizeof(int) == sizeof(long) == sizeof(void *) == 4.
For LP64, sizeof(long) == sizeof(void *) == 8, while sizeof(int) == 4.
We do not support anything else.
Note that this is not true of all downstreams. We currently have 128 and
256-bit void*s with 64-bit longs on CHERI, and I believe that bde???s version
has 32-bit longs on all platforms. This kind of code *is* broken for us and
we???d greatly appreciate people not writing new code that intentionally relies
on undefined behaviour (round tripping a pointer via any integer type other
than intptr_t is undefined in C), when a well-defined mechanism exists, just
because Linux decides to do the wrong thing.
Does CHERI have far pointers or fat pointers? Does it have newlines?
32-bit longs on all platforms is the last thing that I would have. I
have them on 16-bit systems (but I last ran one of those in 2009 after
getting it out of the attic). i386 with correctly-sized longs has
64-bit longs (IP32L64). I never finished that. The tiny amount of
support for this needed in i386/include/_limits.h was removed in 2011
(r217128). gcc just needed to be configured with -DLONG_TYPE_SIZE=64.
Other places mostly just need to use the correct type. Often the fix
is simply to replace long by int or a typedefed type. i386/include/
_types.h was already correct or fixed (mostly by using fixed-width
typedefed types). But sometimes there is an ABI problem. long in an
API literally asks for pessimal double-width sizes, but sometimes what
it needs is precisely 32 ot 64 bits.
Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
