[swift-evolution] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

[Russ Bishop]

One of the alternatives discussed in the proposal was adding mathematical operators to UnsafePointer so you can manipulate the pointers directly, such as XORing them, checking alignment, etc. I would very much prefer that we add operators and functions to UnsafePointer to express intent. 

Converting to Int/UInt is first of all an opportunity for the programmer to screw it up royally (and create massive security holes in the process). I don’t believe supporting operators requires bifurcating into signed/unsigned pointers. Our existing math operators trap on overflow and you must explicitly opt-in to wrapping behavior. For obtaining a distance (which may be negative) we already have distanceTo.

UnsafePointer should have functions to perform various operations while clearly expressing intent, eg: `add(otherPointer: UnsafePointer<T>, limit: Int = Int.max) -> T?` that returns `nil` if the pointer would overflow/underflow. Maybe that’s not the right shape of the API but I strongly feel that we should be discussing that rather than this proposal.


Russ


> On Mar 28, 2016, at 10:53 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> I'm not sure what you mean by "the operator approach". Do you mean measuring the distance between a pointer and nil? That assumes that nil's representation is 0 (which admittedly it is on all our platforms, but which shouldn't really be in anyone's mental model of UnsafePointer).
> 
> I'd like to note that (IIUC) one of our goals is to make unsafeBitCast unneccessary; if a conversion is a reasonable thing to do regularly, there should always be a more principled way to do it. Someone's "intuitive" understanding of unsafeBitCast may well be wrong.
> 
> Jordan
> 
> 
>> On Mar 27, 2016, at 10:01, Russ Bishop via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1. 
>> (If you really know what you're doing you can already do an unsafeBitCast so this isn't a problem I've had in the real world)
>> 
>> >Because some of these operations are defined only on signed integers, and others on unsigned, it would have required splittingUnsafe[Mutable]Pointer into signed and unsigned variants, which would have complicated things for users who did not need to do pointer arithmetic
>> 
>> This proposal doesn't solve that problem; it relies on the user selecting the correct conversion and checking for invalid results. It leaves things just as error-prone as C. I think we /can/ do better and /should/ do better. 
>> 
>> I'd rather see arithmetic operators on UnsafePointer that trap on overflow/underflow, then some functions for checking common scenarios that people always get wrong (how many exploits begin with "this check attempts to determine if size exceeds a bound or wraps but is completely incorrect..."^). Something like "add(Int, max: UnsafePointer = UnsafePointer.max) -> UnsafePointer?" Which returns nil if the value would exceed max or wrap around. 
>> 
>> I guess my main problem is that pointers *are* unsigned. For silly implementation reasons we treat them as signed so we can check some overflow/underflow scenarios but why not just solve the real problem and let people express intent clearly instead of obtusely?**
>> 
>> I've had a lot of experience doing rather unsafe things in Swift and my evaluation is based on that experience. 
>> 
>> Russ
>> 
>> ^ Seriously... This kind of failure has to be responsible for billions of dollars in damages by now. It's an extremely common error. 
>> 
>> ** I'm aware that on many current CPUs the top N bits are either fixed or extended from the highest valid bit so the hardware doesn't actually need to handle a full 64-bit virtual address space. I'm also aware that many architectures place the kernel address space in the upper range so user mode code never sees "negative" pointers. The address space restriction won't be true forever and Swift should be usable to write kernel mode code/drivers in the future. 
>> 
>> 
>> On Mar 22, 2016, at 2:35 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> Hello Swift community,
>>> 
>>> The review of "Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer" begins now and runs through March 25th. The proposal is available here:
>>> 
>>>    https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md <https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md>
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
>>>    https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> or, if you would like to keep your feedback private, directly to the review manager.
>>> 
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>>> 
>>>    * What is your evaluation of the proposal?
>>>    * Is the problem being addressed significant enough to warrant a change to Swift?
>>>    * Does this proposal fit well with the feel and direction of Swift?
>>>    * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>>    * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>>    https://github.com/apple/swift-evolution/blob/master/process.md <https://github.com/apple/swift-evolution/blob/master/process.md>
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160328/d182d3f4/attachment.html>