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 <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
