Skip to content

[cxx-interop] std.string created from [CChar] with 16 elements has additional bytes appended to it #81611

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

Closed
Drejzer opened this issue May 19, 2025 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels

Comments

@Drejzer
Copy link

Drejzer commented May 19, 2025

Description

Sometimes when a std.string is created by passing in [CChar] to std.string(_:), the created string will have some random bytes appended to it.

From what I've seen this occurs when such string is created within a for loop, and only when the array has 16 elements. 15 and 17 element arrays don't seem to produce this behaviour.

Additionally even when the arrays are not the same between iterations, the appended data stays the same.

However, when the code is recompiled in Xcode (because there were changes in code) the issue sometimes does not appear until the code is ran again (or appears in only one of the iterations), while it always happens when using terminal swift run (though only from the second iteration onwards)

Reproduction

In a swift package executable target that enables Cxx interop:

import Foundation

@main
struct test{
  public static func main(){
    for i in 0...3{
      let cc = CChar(97+i)
      let carrs = [CChar]([77, 121, 32, 69, 120, 97, 109, 112, 108, 101, 32,
                           cc, cc, cc, cc])
      let carr = [CChar]([77, 121, 32, 69, 120, 97, 109, 112, 108, 101, 32,
                          cc, cc, cc, cc, cc])
      let carrl = [CChar]([77, 121, 32, 69, 120, 97, 109, 112, 108, 101, 32,
                           cc, cc, cc, cc, cc, cc])

      let strs = std.string(carrs)
      let str = std.string(carr)
      let strl = std.string(carrl)

      let sstrs = String(strs)
      let sstr = String(str)
      let sstrl = String(strl)

      print(carrs,"\n\(strs)","\n\(sstrs)\n")
      print(carr,"\n\(str)","\n\(sstr)\n")
      print(carrl,"\n\(strl)","\n\(sstrl)\n")
    }
  }
}

Expected behavior

A std.string created from an array of 16 CChars will have only those 16 charcters

Environment

swift-driver version: 1.120.5 Apple Swift version 6.1 (swiftlang-6.1.0.110.21 clang-1700.0.13.3)

Additional information

No response

@Drejzer Drejzer added bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels labels May 19, 2025
@CrazyFanFan
Copy link
Contributor

CrazyFanFan commented May 20, 2025

C string should be null-terminated.

@main
struct test{
    public static func main(){
        for i in 0...3{
            let cc = CChar(97+i)
            let carrs = [CChar]([77, 121, 32, 69, 120, 97, 109, 112, 108, 101, 32, cc, cc, cc, cc, 0])
            let carr  = [CChar]([77, 121, 32, 69, 120, 97, 109, 112, 108, 101, 32, cc, cc, cc, cc, cc, 0])
            let carrl = [CChar]([77, 121, 32, 69, 120, 97, 109, 112, 108, 101, 32, cc, cc, cc, cc, cc, cc,0 ])

            let strs = std.string(carrs)
            let str  = std.string(carr)
            let strl = std.string(carrl)

            let sstrs = String(strs)
            let sstr  = String(str)
            let sstrl = String(strl)

            print(carrs, "\n\(strs)", "\n\(sstrs)\n")
            print(carr,  "\n\(str)",  "\n\(sstr)\n")
            print(carrl, "\n\(strl)", "\n\(sstrl)\n")

            print("- - - - - ")
        }
    }
}

@Drejzer
Copy link
Author

Drejzer commented May 20, 2025

Ah yes, null-terminated strings.
I completely forgot about that one, my bad; I should have realised that would be the issue by it being treated as UnsafePointer by the init...

@Drejzer Drejzer closed this as completed May 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. triage needed This issue needs more specific labels
Projects
None yet
Development

No branches or pull requests

2 participants