[swift-evolution] SE-0138 UnsafeBytes

[Andrew Trick]

> On Sep 3, 2016, at 3:36 PM, Drew Crawford <drew at sealedabstract.com> wrote:
> 
> 
> On September 2, 2016 at 2:36:43 AM, Andrew Trick (atrick at apple.com <mailto:atrick at apple.com>) wrote:
> 
>> 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 with this, I think it's mostly a question of naming and defaults.  My concern here is letting a swift developer accidentally write heartbleed, which we can't actually prevent, but we can make it harder.
> 
> IMO 
> 
> 1.  There should be clear consistency in the checked-ness of the API surface.  Agree that checked iterator makes no sense, but I think the most important thing is to avoid creating a job interview trivia game where `set` is checked but `store` is unchecked, spot the bug in this function.
> 
> 2.  For consistency with UnsafeBufferPointer it may make the most sense to just ship unchecked or ship an opt-in checked wrapper.  I believe however that the existing precedent is all wrong on this point, and I'd like to see us revisit this question across both interfaces in Swift 4, but I don't want to lay out a whole case here that should be its own thread.
> 
I generally agree with what you said. I think the vague plan is later in Swift 4 to ship a bounds-checked variant of both UnsafeBufferPointer and UnsafeBytes (or  UnsafeRawBufferPointer if you prefer).

I don’t want to eliminate the debug-mode checks though. I did try to make it clear in the comments that bounds-checking only applied to debug mode, so developers should not accidentally become too reliant on them.

So, the only question is whether the UnsafeBytes.copyBytes() API should have debug or release-mode checks. My decision to keep the stronger checks here was probabilistic—it seems unlikely to be a performance issue but likely to catch most buffer overruns. But I agree that it is inconsistent, especially if we plan to introduce a release bounds-checked variant later. We don’t want developers to begin relying on that check. I’m leaning toward dropping it down to a debug-mode check.

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