[swift-evolution] Proposal: Add Initializers For Converting UnsafePointers to Int and Unit

[Dmitri Gribenko]

Hi Michael,

Thank you for working on this proposal!

On Tue, Dec 8, 2015 at 7:54 PM, Michael Buckley via swift-evolution <
swift-evolution at swift.org> wrote:

> UnsafePointer and UnsafeMutablePointer both contain initializers to
> convert from Int and Uint, but Int and UInt lack initializers to convert
> from UnsafePointer and UnsafeMutablePointer. Over in swift-dev, Dimitri
> Gribenko proposed adding something like the following initializers to
> stdlib.
>
> 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
>
> There are two motivations behind this proposal. First, it would allow more
> complicated pointer arithmetic, such as checking pointer alignment. Second,
> some C functions take intptr_t and uintptr_t parameters, which are not
> compatible with UnsafePointer.
>
> As noted in UnsafePointer.swift.gyb the conversions from UInt and Int are
> fundamentally unsafe, and these proposed conversions would also be unsafe.
> They would also allow for more unsafe pointer arithmetic operations. For
> example, it would allow users to convert two UnsafePointers to UInt8s in
> order to find the distance between them, which would be a problem if the
> user subtracted the larger pointer from the smaller pointer.
>

Another use case is tagged pointers, which there are at least two flavors
of: Lisp-style (low bits are the tag), or NSString-style (the pointer
payload contains character data).

We could consider adding APIs for tagged pointers, too (although I'm
concerned that an API that exposes the operations with zero overhead would
be probably as unsafe as direct arithmetic and possibly more clumsy and
less readable).

A meta point is, though, that Swift, being a systems programming language,
should allow expressing these patterns (working with alignment, creating
tagged pointers), and any other things people might imagine (e.g., a XOR
linked list) directly in the language, without builtins.

Because of this, and because it's part of the Swift evolution process, it's
> worth considering alternatives. Pointer arithmetic could be taken care of
> by adding functions to UnsafePointer, and these may be worth proposing
> separately. I'm thinking something like this.
>
> func distanceToBoundary(_ boundary: Int) -> Int {
>     return Int(Builtin.ptrtoint_Word(self._rawValue)) % boundary
> }
>
> func isAlignedToBoundary(_ boundary: Int) -> Bool {
>     return distanceToBoundary(boundary) == 0
> }
>

Then one would also need two other methods, I think: to align the pointer
to the nearest boundary, up and down.

As for intptr_t parameters, the only alternative I can think of is to
> require users to write adaptor functions in C. Requiring users to write C
> code also works for pointer alignment and other pointer arithmetic, but it
> doesn't feel like a great solution to the problem.
>

Even writing wrappers for intptr_t doesn't feel great.  One of the goals is
to be able to wrap C libraries and improve their API by augmenting with
Swift code to the extent possible (for multiple reasons).

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>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/f06d325a/attachment.html>