[swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2
Philippe Hausler
phausler at apple.com
Thu Aug 24 14:35:21 CDT 2017
This is expected behaviors of collections and their slices. The previous result was a bug.
I agree that collections in general and their slices need more documentation.
Sent from my iPhone
> On Aug 24, 2017, at 11:28 AM, Ryan Lovelett <swift-dev at ryan.lovelett.me> wrote:
>
> I think your onto it Philippe but then why is it behaving that way?
>
> I updated my earlier script (attached) and added 2 things.
>
> 1. print("Start: \(data.startIndex), End: \(data.endIndex), Count: \(data.count)") after the data.removeFirst(4).
> 2. The startIndex offset you suggested.
>
> It no longer crashes. Hooray!
>
> Swift 3.1:
>
> Start: 0, End: 2, Count: 2
> Base64: QWE=, String: Aa
>
> Swift 3.2:
>
> Start: 4, End: 6, Count: 2
> Base64: QWE=, String: Aa
>
> Oh wait. Woah. That's a really subtle change that has some very real consequences.
>
> Is this expected and/or documented? Because I certainly would not have expected that drastic of a change. I'll obviously need to go read a lot more of the changes between Swift 3.1 and Swift 3.2 if these sorts of changes are in scope.
>
>
>> On Thu, Aug 24, 2017, at 02:10 PM, Philippe Hausler wrote:
>> I see the issue.. the latest version traps (appropriately so).
>>
>> let str = String(bytes: data[0..<2], encoding: .utf8)!
>>
>> The sub-range of the slice you have is incorrectly indexed. Try this out (I am presuming this is what you mean):
>>
>> let str = String(bytes: data[data.startIndex..<(data.startIndex + 2)], encoding: .utf8)!
>>
>>> On Aug 24, 2017, at 11:07 AM, Philippe Hausler <phausler at apple.com> wrote:
>>>
>>> Is there a radar or bugs.swift.org ticket filed on this?
>>>
>>> I presume because of the import this is a Darwin thing and not a linux thing.
>>>
>>>> On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev <swift-dev at swift.org> wrote:
>>>>
>>>>
>>>>> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift-dev at swift.org> wrote:
>>>>>
>>>>> I've found what I believe is a bug. Though I'm unclear if the bug is in
>>>>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the behavior is
>>>>> quite drastically different between the two.
>>>>>
>>>>> For the code below (and attached):
>>>>>
>>>>> import Cocoa
>>>>>
>>>>> var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>>>> data.removeFirst(4)
>>>>> let base64 = data.base64EncodedString()
>>>>> let str = String(bytes: data[0..<2], encoding: .utf8)!
>>>>> print("Base64: \(base64), String: \(str)")
>>>>>
>>>>> If I compile and run that with the Swift included in Xcode 8.3.3 (e.g.,
>>>>> swift ./data-bug.swift) it outputs: Base64: QWE=, String: Aa. Which is
>>>>> what I expect.
>>>>>
>>>>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v) (e.g.,
>>>>> swift -swift-version 3 ./data-bug.swift). It performs an illegal
>>>>> hardware instruction and crashes. It also does this if I use use the
>>>>> version 4 of the compiler.
>>>>>
>>>>> Is this a bug? If so where is the bug? Was this always meant to not work
>>>>> and Swift 3.1 just happened to work or is there now an issue in the
>>>>> Swift 3.2 implementation?
>>>>
>>>> I have not engaged my brain with the particulars of the rest of the email, but high level question: does this happen without optimization? Or does it happen only with optimization?
>>>>
>>>> Michael
>>>>
>>>>> <data-bug.swift>_______________________________________________
>>>>> swift-dev mailing list
>>>>> swift-dev at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>>
>>>> _______________________________________________
>>>> swift-dev mailing list
>>>> swift-dev at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>
> <data-bug.swift>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170824/e04d5616/attachment.html>
More information about the swift-dev
mailing list