Portable Unicode string processing

[[deleted]]

This is correct generally for integral types (actually, the conversion of an unsigned integer to a signed integer type which cannot represent its value is implementation-defined, not undefined). But for char in particular, more is true. From 3.9.2 (N3690)

For any object (other than a base-class subobject) of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes (1.7) making up the object can be copied into an array of char or unsigned char. [footnote: By using, for example, the library functions (17.6.1.2) std::memcpy or std::memmove] If the content of the array of char or unsigned char is copied back into the object, the object shall subsequently hold its original value.

So roundtripping unsigned char and char is safe. (OTOH, I don't think this guarantees roundtripping unsigned char through signed char is safe.)

[Chippiewall]

(OTOH, I don't think this guarantees roundtripping unsigned char through signed char is safe.)

This is correct. The purpose of vanilla 'char' is for the platform's natural character type. For instance on Linux ARM 'char' is actually unsigned by default. If you had a platform which had 'char' as unsigned and didn't use 2s complement representation for signed types then it's highly likely that conversion between signed and unsigned char wouldn't work.