Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-6757] Data.enumerateBytes gives inconsistent indexes #3746

CharlesJS opened this issue Jan 14, 2018 · 5 comments

[SR-6757] Data.enumerateBytes gives inconsistent indexes #3746

CharlesJS opened this issue Jan 14, 2018 · 5 comments


Copy link

CharlesJS commented Jan 14, 2018

Previous ID SR-6757
Radar rdar://problem/36917972
Original Reporter @CharlesJS
Type Bug
Status Resolved
Resolution Duplicate

Attachment: Download


Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)

Apple Swift version 4.1-dev (LLVM bdcc78a6ed, Clang 27a368e018, Swift 2e48f09e2e)

Apple Swift version 4.1 (swiftlang-902.0.34 clang-902.0.30)

Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Bug
Assignee None
Priority Medium

md5: 5965ddf0411387d0f28422c8af81a84c


  • SR-6515 Subdata of Data returned from URLSession is equal, but has different hash value

Issue Description:

The second argument in the closure passed to Data's enumerateBytes method is a Data.Index. But, of course, the Data being operated on may be a slice. So does the index parameter represent a zero-based index offset from the beginning of the data, as in Swift 3, or does it start at a non-zero .startIndex as in Swift 4?

The answer is... yes!

When running the project described below:


+ (NSData *)makeMeAData {
    dispatch_block_t dtor = DISPATCH_DATA_DESTRUCTOR_DEFAULT;
    dispatch_data_t data1 = dispatch_data_create("feliscatus", 10, nil, dtor);
    dispatch_data_t data2 = dispatch_data_create("isyour", 6, nil, dtor);
    dispatch_data_t data3 = dispatch_data_create("taxonomic", 9, nil, dtor);
    dispatch_data_t data4 = dispatch_data_create("nomenclature", 12, nil, dtor);
    dispatch_data_t data5 = dispatch_data_create_concat(
        dispatch_data_create_concat(dispatch_data_create_concat(data1, data2),
                                    data3), data4);
    return (NSData *)data5;



import Foundation

let dispatchData = DataMaker.makeMeAData()
let nonDispatchData = "feliscatusisyourtaxonomicnomenclature".data(using: .ascii)!

print("enumerating dispatch data")
dispatchData[(dispatchData.startIndex + 5)...].enumerateBytes { ptr, idx, _ in
    print("idx: \(idx) slice: \(String(decoding: ptr, as: UTF8.self))")

print("enumerating non dispatch data")
nonDispatchData[(nonDispatchData.startIndex + 5)...].enumerateBytes { ptr, idx, _ in
    print("idx: \(idx) slice: \(String(decoding: ptr, as: UTF8.self))")

we get the following output:

enumerating dispatch data
idx: 5 slice: catus
idx: 10 slice: isyour
idx: 16 slice: taxonomic
idx: 25 slice: nomenclature
enumerating non dispatch data
idx: 0 slice: catusisyourtaxonomicnomenclature

As you see, the index is zero-based for a pure-Swift data slice, but is non-zero-based for a Data that began life as a dispatch_data_t from Objective-C. So the upshot is that if you use the index for anything, the result will be like the proverbial box of chocolates.

Copy link

belkadan commented Jan 16, 2018

I believe @phausler got all of these in Swift 4.1, but I'll let him make the call.

Copy link

CharlesJS commented Jan 16, 2018

Just tried it with yesterday's Swift 4.1 dev snapshot—still seems to be occurring.

Copy link

CharlesJS commented Jan 26, 2018

Still occurs with the Swift 4.1 distribution included in the Xcode 9.3 beta (9Q98q).

Copy link

belkadan commented Jan 26, 2018

@swift-ci create

Copy link

phausler commented Jan 29, 2018

This is the same issue as before. it is just an invalid index calculation that in some cases would heap corrupt and others just index incorrectly.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants