[swift-corelibs-dev] [swift-dev] Foundation Data Behavior Different (read: crashes) in Swift 3.1 and Swift 3.2

[Ryan Lovelett]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20170824/b06b73f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data-bug.swift
Type: application/octet-stream
Size: 349 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20170824/b06b73f4/attachment.obj>