RESOLVED FIXED Bug 200675
Rename StringBuilder::append(UChar32) to StringBuilder::appendCharacter(UChar32) to avoid accidental change in behavior when replacing append with flexibleAppend
https://bugs.webkit.org/show_bug.cgi?id=200675
Summary Rename StringBuilder::append(UChar32) to StringBuilder::appendCharacter(UChar...
Sam Weinig
Reported 2019-08-13 09:22:55 PDT
Rename StringBuilder::append(UChar32) to StringBuilder::appendCharacter(SUChar32) to avoid accidental change in behavior when replacing append with flexibleAppend
Attachments
Patch (15.96 KB, patch)
2019-08-13 09:33 PDT, Sam Weinig
darin: review+
Sam Weinig
Comment 1 2019-08-13 09:28:44 PDT
When we switch StringBuilder::append(...) to be based on the StringConcatenate/makeString flexibleAppend implementation, if we don't change anything, the behavior of StringBuilder::append(UChar32) will go from appending a character to appending a stringified number. To work around this, we can rename StringBuilder::append(UChar32) to StringBuilder::appendCharacter(UChar32) and update all the call sites.
Sam Weinig
Comment 2 2019-08-13 09:30:41 PDT
Longer term, it would be nicer to have a better solution for this, and one that can be used consistently between makeString() and StringBuilder. The only idea I have right now is adding a struct Character/CodePoint { UChar32 } that people can wrap UChar32s in.
Sam Weinig
Comment 3 2019-08-13 09:33:48 PDT
Darin Adler
Comment 4 2019-08-13 09:59:21 PDT
Comment on attachment 376174 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=376174&action=review > Source/WTF/wtf/FileSystem.cpp:185 > + result.appendCharacter(toASCIIHexValue(inputString[i + 2], inputString[i + 3]) << 8 | toASCIIHexValue(inputString[i + 4], inputString[i + 5])); This looks like it’s a 4 digit hex value. No reason to convert that to UChar32 instead of UChar. Could just use a local UChar instead. > Source/WebCore/css/CSSMarkup.cpp:101 > + appendTo.appendCharacter(0xfffd); This one doesn’t need the UChar32 overload and is only getting that one because the constant 0xfffd is int, not UChar. Could use the replacementCharacter UChar constant from CharacterNames.h instead and then would be able to use the normal append instead. > Source/WebCore/platform/mock/mediasource/MockBox.cpp:54 > + builder.appendCharacter(array->item(i)); An 8-bit integer doesn’t need to be appended as a UChar32. The item function returns an int, but one that’s guaranteed to be an 8-bit signed integer, I think. Maybe we should add a typecast here instead of calling appendCharacter? > Source/WebCore/platform/mock/mediasource/MockBox.cpp:75 > + builder.appendCharacter(array->item(i)); Ditto.
Darin Adler
Comment 5 2019-08-13 10:26:24 PDT
Comment on attachment 376174 [details] Patch Another thought: We might want at least one overload of appendCharacter even if they are deleted so we don’t call this slightly more expensive function accidentally. For types like char, UChar and LChar.
Sam Weinig
Comment 6 2019-08-13 20:15:04 PDT
Radar WebKit Bug Importer
Comment 7 2019-08-13 20:16:25 PDT
Note You need to log in before you can comment on or make changes to this bug.