svn commit: r290711 - head/sys/ofed/drivers/infiniband/core

[Bruce Evans]

On Fri, 13 Nov 2015, David Chisnall wrote:

> On 13 Nov 2015, at 08:35, Konstantin Belousov <kostikbel at 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