Closed straight-shoota closed 3 months ago
Do you think this is fine for 32-bit targets or even AVR?
Yes, it's fine. This is not changing anything from the current status. So compatibility with smaller architectures is not really relevant to this PR. Everything that worked before this PR, should continue to work.
Pointer.new(Int)
is implemented the same way:
This patch merely pulls out the cast to_u64!
to the call size.
A portable implementation would be possible with a uintptr_t
type (and appropriate cast methods).
The one advantage is that now these pointer constants will be actual consts, and no more wrapped in a Crystal::Once to be defined at runtime.
Though I'm wondering if we couldn't introduce a Pointer::Size
type (currently set to UInt64) to prepare for the introduction of a target specific pointer size :thinking:
@ysbaddaden Yes, I think we should do that. But it's a separate change. We can easily come back to update these definitions then. And there'll be a lot more which need this treatment.
Are you sure it's separate? Introducing a target specific Pointer::Size might be, but introducing a hardcoded Pointer::Size as UInt64 seems like it would fit just right in to me.
IMO introducing Pointer::Size
even if as an alias to UInt64
is a separate change. Now we could pull that up and merge it before this PR. But I see little benefit. They can be merged in any order.
This is a preparatory step to dropping the overload
Pointer.new(Int)
(#14669). It replaces all calls to this overloads with explicit casts toUInt64
at the call site, which ends up resolving to the main overloadPointer.new(UInt64)
.