[swift-dev] Starter project: Initializers for converting UnsafePointers to integers

[Michael Buckley]

Checking alignment good use case, which I did not consider. Not to turn
this into a swift-evolution topic, but couldn't this use case be covered by
adding functions to UnsafePointer? I'm thinking something like this.

func distanceToBoundary(_ boundary: Int) -> Distance {
    return Builtin.ptrtoint_Word(self._rawValue) % boundary
}

func isAlignedToBoundary(_ boundary: Int) -> Boolean {
    return distanceToBoundary(boundary) == 0
}

I'll admit I don't have a lot of experience working with algorithms which
check pointer alignment. If you need a check that requires a more
complicated equation, then yeah, converting UnsafePointers to Ints is
probably the best solution. But if possible, it's probably best to avoid
requiring users to convert to int and back. They not only need to write
less code if UnsafePointers can take care of this for them, but it also
prevents subtle bugs they may write. (E.g. Converting 2 UnsafePointers to
UInts and then subtracting them to find the distance, but subtracting the
larger pointer from the smaller one).

On Tue, Dec 8, 2015 at 8:45 AM, Stephen Canon <scanon at apple.com> wrote:

> When writing high-performance code, it is fairly common to check the
> alignment of pointers so that initial elements can be processed until some
> suitable alignment is reached to use a faster implementation, or to verify
> that a fast algorithm can be used.
>
> On Dec 8, 2015, at 10:59 AM, Michael Buckley via swift-dev <
> swift-dev at swift.org> wrote:
>
> I'm looking for a good starter project, so normally I would be interested
> in taking this, but I'm not sure I can think of a good motivation for it.
> UnsafePointer's advanceBy and distanceTo functions take care of pointer
> arithmetic more safely than converting to int would, and the
> debugDescription property can get you the address for debugging purposes.
>
> Considering that everything that goes through the swift-evolution process
> needs to have a motivation, is there a use case for this that I'm not
> thinking of?
>
> On Mon, Dec 7, 2015 at 4:45 PM, Dmitri Gribenko via swift-dev <
> swift-dev at swift.org> wrote:
>
>> Hi everyone,
>>
>> The standard library has bitPattern initializers on pointers. But we
>> are missing initializers to create integers from pointers.
>>
>> Someone needs to propose these APIs, walk them through
>> swift-evolution, write a patch for the library and add tests.
>>
>> extension UInt {
>>   init<T>(bitPattern: UnsafePointer<T>) {
>>     self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>>
>>   init<T>(bitPattern: UnsafeMutablePointer<T>) {
>>     self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>> }
>>
>> extension Int {
>>   init<T>(bitPattern: UnsafePointer<T>) {
>>     self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>>
>>   init<T>(bitPattern: UnsafeMutablePointer<T>) {
>>     self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))
>>   }
>> }
>>
>> https://bugs.swift.org/browse/SR-131
>>
>> Dmitri
>>
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151208/4e780956/attachment.html>