> On Sep 1, 2016, at 5:37 PM, Andrew Trick <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
