[swift-evolution] SE-0138 UnsafeBytes

[Dave Abrahams]

on Fri Sep 02 2016, Andrew Trick <swift-evolution at swift.org> wrote:

>> 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. 

I agree, but would like to carefully design how we do this in
conjunction with Unsafe[Mutable]BufferPointer.  For example, maybe

      p.boundsChecked

gives you an UnsafeBoundsChecked[Mutable][Raw]BufferPointer.

So I think this should be a separate proposal.

> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave