[swift-evolution] SE-0138 UnsafeBytes

[Andrew Trick]

> On Sep 1, 2016, at 5:37 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> The proposal is available here:
> 
>  <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md>>
> 
>> On Sep 1, 2016, at 4:59 PM, Drew Crawford <drew at sealedabstract.com <mailto:drew at sealedabstract.com>> wrote:
>> I'm possibly one of the larger users of raw byte stuff in Swift as I maintain an entire client/server network protocol stack in Swift userspace, similar in spirit to one of the examples drawn out a lot longer.  Grepping my code produces over 200 individual uses of unsafe byte accesses.
>> 
>> I definitely agree that the problem is significant enough to warrant a last-minute change.
>> 
>> To a first approximation I agree with all the implementation choices.  The naming, the choice of UInt8, length tracking, and debug-bounds checking are all correct IMO.  We have been using something similar for a long time internally [have you been reading my code? :-) ] so I can speak from experience that the basic plan here is sound.
>> 
>> One thing I would like to see is an (opt-in) release-mode-bounds-check.  Networking is a core use case for this feature, but when you are reading from a socket, production is where you need a guard against out-of-bounds UB the most.  If we can't solve it for Swift 3, affected users can write a wrapper to implement the boundscheck, but I think we should at very least take it up again for Swift 4.
>> 
>> Drew
> 
> In my current implementation:
> https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb <https://github.com/atrick/swift/blob/unsafebytes/stdlib/public/core/UnsafeBytes.swift.gyb>
> 
> The bounds checks in `copyBytes(from:)` are release mode preconditions.
> 
> The bounds checks for `subscript`, `load(as:)`, and `storeBytes(of:as:)` are debug only because it’s likely they occur in some loop that could be covered by a single bounds check. By extension, the sequence iterator is only bounds checked in debug mode.
> 
> One possibility would be different names for the bounds checked forms of those methods: getByte(atOffset:), setByte(atOffset:), load(fromCheckedOffset:as:), storeBytes(of:toCheckedOffset:as:). Along with some kind of bounds checked Iterator.
> 
> I don’t think makes a lot of sense as generic Collection though. Alternatively, we just have an UnsafeBoundsCheckedBytes wrapper.
> 
> This would a good thing to experiment with in your project. We may be able to follow-up with a Swift 4 proposal. The important thing now is to determine whether the proposed Swift 3 design will make that wrapper difficult in any way.

After thinking about this for a moment, I like the approach of extending UnsafeBytes with release-mode bounds checked versions of subscript, load, and storeBytes. It’s not actually meaningful to have a bounds checked iterator for UnsafeBytes. A wrapper would only be useful to guard against accidentally circumventing the bounds checks, but I’m not sure that’s really helpful in practice. It seems that a framework would want to provide more abstract Socket I/O or network message abstractions and those wrappers would just call the bounds checked version of the UnsafeBytes APIs.

-Andy

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