Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 7e37c8055ae18c4fc75b5b5b6e1d1d11b7e02287
https://github.com/WebKit/WebKit/commit/7e37c8055ae18c4fc75b5b5b6e1d1d11b7e02287
Author: Chris Dumez <[email protected]>
Date: 2026-09-14 (Mon, 14 Sep 2026)
Changed paths:
M Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorUtils.cpp
M Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorUtils.h
M Source/JavaScriptCore/wasm/WasmNameSection.h
M Source/WTF/wtf/HexNumber.cpp
M Source/WTF/wtf/HexNumber.h
M Source/WTF/wtf/SHA1.cpp
M Source/WTF/wtf/SHA1.h
M Source/WTF/wtf/text/CString.h
M Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm
M Tools/TestWebKitAPI/Tests/WTF/CString.cpp
Log Message:
-----------
Make the hex digest helpers return an ASCIICString and keep their consumers
typed
https://bugs.webkit.org/show_bug.cgi?id=324076
Reviewed by Ben Nham.
toHexCString(), SHA1::hexDigest() and SHA1::computeHexDigest() all produce hex
digits, so
their output is ASCII by construction. Returning ASCIICString says so in the
type instead
of leaving it to the function name, and CStringWithEncoding's span constructor
asserts
charactersAreAllASCII(), so the claim is now checked in debug builds rather
than assumed.
There is no call-site churn: ASCIICString spells ASCII with char, so data() is
still
const char* and span() is still std::span<const char>, exactly as they were on
CString.
The call sites that store the result in a CString keep working through the
implicit
slice to the base class.
Three consumers propagate the type one level further rather than erasing it:
backendCommandsHash() and NameSection::setHash() now hold an ASCIICString, and
computeStringHashForContentBlockerRules() calls createNSString() on the digest
directly
instead of routing it through String::fromUTF8(). That last one decodes as
Latin-1 rather
than UTF-8, which createNSString() picks for char; the two are identical for
hex digits,
and both map a null string to @"".
Adopting ASCIICString also surfaced two things to tidy in the type itself. Its
comment said
char is ASCII, which contradicts CString, where a char means "any encoding"
seven lines up;
char is only ASCII's representation, chosen because const char* is what C
string interfaces
take, which is what an ASCII string is for. And legacyCStringPointer() was
offered for both
char and char8_t, where for char it just duplicated data(); nothing in the tree
called it on
an ASCIICString, so it is now constrained to UTF-8, leaving
ASCIICString::data() as the one
way to reach a const char*.
* Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorUtils.cpp:
(Inspector::backendCommandsHash):
* Source/JavaScriptCore/inspector/remote/glib/RemoteInspectorUtils.h:
* Source/JavaScriptCore/wasm/WasmNameSection.h:
(JSC::Wasm::NameSection::setHash):
* Source/WTF/wtf/HexNumber.cpp:
(WTF::toHexCString):
* Source/WTF/wtf/HexNumber.h:
* Source/WTF/wtf/SHA1.cpp:
(WTF::SHA1::hexDigest):
(WTF::SHA1::computeHexDigest):
* Source/WTF/wtf/SHA1.h:
* Source/WTF/wtf/text/CString.h:
(WTF::CStringWithEncoding::legacyCStringPointer):
* Source/WebKit/UIProcess/Extensions/Cocoa/WebExtensionContextCocoa.mm:
(WebKit::computeStringHashForContentBlockerRules):
Canonical link: https://commits.webkit.org/321139@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
