Avoid utf8CString when when owned storage is not required

[jmschonfeld]

Avoids calling utf8CString when not necessary

Motivation:

I noticed we use String.utf8CString in a handful of places in Foundation. Since this property returns a ContiguousArray<CChar> which is an owned type, it must copy the contents of the string into an array. Instead, we can use withCString which provides the same functionality, but can avoid a copy if the String already contains null terminated UTF-8 (which native strings do). Additionally, in some cases, we didn't actually need a null terminated string and we can use withUTF8 instead which also avoids copying when the String contains non-null terminated UTF-8 (which some bridged strings do as well). This should avoid copying these strings each time (when not required)

Modifications:

Replace uses of utf8CString with withCString/withUTF8

Result:

Copies are avoided when the string can provide access to an inner cstring or utf8 pointer

Testing:

Existing tests cover these modified functions

[jmschonfeld]

@swift-ci please test

[kperryua]

Looks like more of the C function pointer nullability mismatch.

[jmschonfeld]

cannot convert value of type 'UnsafePointer<UInt8>' to expected argument type 'UnsafePointer<CChar>?' (aka 'Optional<UnsafePointer<Int8>>') because var 'ucasemap_utf8ToLower' was not imported from C header

Well, this is quite strange because ucasemap_utf8ToLower certainly is imported from a C header. I suspect that this has something to do with the macro aliasing feature. @compnerd @xedin similar to the attribute that we were missing to declare these aliases had no storage (to silence concurrency warnings), are we also missing some attribute on the imported decl to declare that it came from a C header so that these types of mappings are allowed?

[compnerd]

@jmschonfeld no, I don't think that this conversion is allowed. This is an issue related to -fsigned-char vs -funsigned-char.

[jmschonfeld]

@jmschonfeld no, I don't think that this conversion is allowed. This is an issue related to -fsigned-char vs -funsigned-char.

Given that macOS CI passed, this conversion must be allowed in some situations and the only difference in this function between macOS and Linux/Windows etc. is the symbol renaming I believe (which is disabled on macOS)

[jmschonfeld]

@jmschonfeld no, I don't think that this conversion is allowed. This is an issue related to -fsigned-char vs -funsigned-char.

Given that macOS CI passed, this conversion must be allowed in some situations and the only difference in this function between macOS and Linux/Windows etc. is the symbol renaming I believe (which is disabled on macOS)

Oh sorry I misunderstood. Yeah it looks like even building on macOS with the symbol renaming enabled it builds successfully, so sounds like it's a platform difference between the value of what CChar is based on those build flags you mentioned?

[jmschonfeld]

@swift-ci please test

[jmschonfeld]

@swift-ci please test

[compnerd]

@jmschonfeld no, I don't think that this conversion is allowed. This is an issue related to -fsigned-char vs -funsigned-char.

Given that macOS CI passed, this conversion must be allowed in some situations and the only difference in this function between macOS and Linux/Windows etc. is the symbol renaming I believe (which is disabled on macOS)

Oh sorry I misunderstood. Yeah it looks like even building on macOS with the symbol renaming enabled it builds successfully, so sounds like it's a platform difference between the value of what CChar is based on those build flags you mentioned?

It isn't flag related, it is the platform ABI. Windows and Darwin disagree on what a char should be.

[jmschonfeld]

@swift-ci please test

[jmschonfeld]

@swift-ci please test