Does it? According to the documentation for the current decodeCString <https://developer.apple.com/reference/swift/string/1641442-decodecstring>, it seems to accept an UnsafePointer, not a buffer pointer, and expects the string to be null-terminated. Am I missing another overload?
> Le 30 mars 2017 à 17:27, Zach Waldowski via swift-evolution > <[email protected]> a écrit : > > On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote: >> I don't have much non-nitpick issues that I greatly care about; I'm in favor >> of this. >> >> My only request: it's currently painful to create a String from a fixed-size >> C array. For instance, if I have a pointer to a `struct foo { char name[16]; >> }` in Swift where the last character doesn't have to be a NUL, it's hard to >> create a String from it. Real-world examples of this are Mach-O LC_SEGMENT >> and LC_SEGMENT_64 commands. >> >> >> The generally-accepted wisdom <http://stackoverflow.com/a/27456220/251153> >> is that you take a pointer to the CChar tuple that represents the fixed-size >> array, but this still requires the string to be NUL-terminated. What do we >> think of an additional init(cString:) overload that takes an >> UnsafeBufferPointer and reads up to the first NUL or the end of the buffer, >> whichever comes first? > > Today's String already supports this through > `String.decodeCString(_:as:repairingInvalidCodeUnits:)`, passing a buffer > pointer. > > Best, > Zachary Waldowski > [email protected] <mailto:[email protected]> > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
