Clean up String::create handling with HX_SMART_STRINGS disabled #1253
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
d119a07 fixed an issue with incorrect handling of
length < 0
, however, it also introduced an unnecessary additional loop to get the length of the string, separate from the conversion/copy loop. This can be cleaned up becauseGCStringDup
already has the correct handling oflength < 0
, and forTConvertToUTF8
putting length as 0 has the same effect. This way the string only has to be iterated through once for the conversion/copy.Also, there was still broken behaviour when using
String::create(_, 0)
. WithHX_SMART_STRINGS
, this always returns an empty string, whereas withoutHX_SMART_STRINGS
the behaviour depends on the char type. This PR fixes this so it always returns an empty string.This also adds a test for #849, to make sure it doesn't cause a regression. (Presumably, #814 is also covered by this test)