> On Sep 3, 2016, at 3:36 PM, Drew Crawford <d...@sealedabstract.com> wrote:
>
>
> On September 2, 2016 at 2:36:43 AM, Andrew Trick (atr...@apple.com
> <mailto:atr...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
