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'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
···
On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift-dev@swift.org> 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@swift.org> wrote:
On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift-dev@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?
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@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@swift.org> wrote:
On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift-dev@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?
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@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@swift.org> wrote:>>>
On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift- >>>> dev@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
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@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@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@swift.org> wrote:
On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift-dev@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?
Understood. Luckily we had a pretty decent test suite that caught this.
Thanks for working through that with me Philippe.
···
On Thu, Aug 24, 2017, at 03:35 PM, Philippe Hausler wrote:
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@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[..<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@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@swift.org> wrote:>>>>>
On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift- >>>>>> dev@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
>>>>>> 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
>>>>>> 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