Disallow creation of CFStrings from non-8bit c-strings #5165
Conversation
|
@swift-ci please test |
| if (hasNullByte && !__CFStringEncodingIsSupersetOfASCII(encoding)) { | ||
| // Non-8bit encodings cannot be safely read as c-strings because they may contain many null bytes | ||
| // This was documented as invalid previously, but now we validate that eagerly here to prevent creating truncated strings or strings that incorrectly assume 8bit representation | ||
| HALT_MSG("CFStringCreateWithCString can only be called with an 8-bit encoding"); |
There was a problem hiding this comment.
Do you think it might be possible that people are calling this with some non-8bit encoding, but only ASCII data, and getting away with it today?
There was a problem hiding this comment.
For many encodings I suspect they couldn't get away with it (for example in UTF-16 ASCII text would have a lot of intermediate null bytes so depending on the endianness either string creation would fail (because there would be an odd number of bytes) or the string would be empty (because the first byte is a null byte)). So it's possible that someone could be relying on the failing (NULL return) or empty string behavior, but I think that's not super likely. It's possible that there's another encoding that we have that might work - I can double check - but I can't think of one off the top of my head that would behave correctly
It is invalid to create a
CFStringfrom a c-string of a non-8bit encoding. Encodings that are not 8bit encodings may have embedded null bytes that represent a portion of a scalar (for example, the leading byte of an ASCII scalar represented in UTF-16) which means these encodings are not suitable for c-string representation. Currently, we do not enforce this and creation can sometimes fail, sometimes truncate the provided text, and other times create a malformedCFStringwhich may behave unexpectedly when callingCFStringGetCStringPtron it (it can vend a pointer of the wrong encoding). This change enforces this requirement by trapping at runtime if an invalid encoding is provided.I left some comments in
CFStringGetCStringPtrabout the potentially confusing behavior that previous arose here due to this issue with an explanation about how the enforcement at string creation time makes the logic in that function sound.Resolves #5164