kern: don't make pointer/int casting fatal

[imp]

Summary

gcc seems to warn too much, so don't make it an error.

Sponsored by: Netflix

[jhb]

CHERI is about to break all these anyway. What actual errors are you seeing with the kernel now? When I get armv7 building for GCC we probably want to fix all these properly anyway? So far I'm still trying to get armv7 world building so haven't even looked at the kernel.

[imp]

In D56409#1291371, @jhb wrote:

CHERI is about to break all these anyway. What actual errors are you seeing with the kernel now? When I get armv7 building for GCC we probably want to fix all these properly anyway? So far I'm still trying to get armv7 world building so haven't even looked at the kernel.

Bogus complaints in the iflib code that masks off the lower bits of the pointer using: (struct mbuf *)((uintptr_t)m & mask). for pointer-to-int and I forget for the int-to-pointer. It's totally fine. Of course, marking the pointer this way to avoid a de-reference before invalidating / finishing the transaction seems like too much of a micro-optimization to be worth it.

[jhb]

I don't understand how the (struct mbuf *)((uintptr_t)m & mask)) would trigger this? The warnings I had in stand/ with EFI were all legit "casting uint64_t to pointer" or vice versa without a uintptr_t cast, and I fixed those by adding a uintptr_t cast. Presumably the result of the inner expression should be of type uintptr_t and not int? Of course, I'd rewrite those today to use __align_down, then you can do something like: __align_down(m, (~mask + 1)) (but probably the latter is easily to-hand as a constant, e.g. __align_down(m, 16) or the like) without needing any casts (align_down and align_up are type preserving).

[imp]

In D56409#1291946, @jhb wrote:

I don't understand how the (struct mbuf *)((uintptr_t)m & mask)) would trigger this? The warnings I had in stand/ with EFI were all legit "casting uint64_t to pointer" or vice versa without a uintptr_t cast, and I fixed those by adding a uintptr_t cast. Presumably the result of the inner expression should be of type uintptr_t and not int? Of course, I'd rewrite those today to use __align_down, then you can do something like: __align_down(m, (~mask + 1)) (but probably the latter is easily to-hand as a constant, e.g. __align_down(m, 16) or the like) without needing any casts (align_down and align_up are type preserving).

It's a gcc bug is why. It should be totally fine, but the __align_down stuff would be better. this is just a hack to make gcc happy.