{"id":748,"date":"2026-03-11T10:02:28","date_gmt":"2026-03-11T09:02:28","guid":{"rendered":"https:\/\/blogs.igalia.com\/xrcalvar\/?p=748"},"modified":"2026-03-11T10:02:28","modified_gmt":"2026-03-11T09:02:28","slug":"reworking-string-management-in-webkits-gstreamer-code","status":"publish","type":"post","link":"https:\/\/blogs.igalia.com\/xrcalvar\/2026\/03\/11\/reworking-string-management-in-webkits-gstreamer-code\/","title":{"rendered":"Reworking string management in WebKit’s GStreamer code"},"content":{"rendered":"

When you work on WebKit’s GStreamer code, you end up dealing with strings a lot. GStreamer and GLib APIs use C strings everywhere: element names, property values, caps descriptions, SDP fields… The list is long. The problem was that we were handling all those strings in a somewhat inconsistent way, and the interaction between C strings and WebKit’s own string types was not as clean as it should be.<\/p>\n

This is why I started a meta-effort (Bug 289787<\/a>) to rework how we manage strings in the GStreamer code of WebKit. The outcome is mainly two new classes: CStringView<\/code> and GMallocString<\/code>. In this post I want to explain what they are and why they were needed.<\/p>\n

The problem<\/h2>\n

WebKit has its own string types, like WTF::String<\/code> and WTF::CString<\/code>, which are designed around WebKit’s internal needs. They handle reference counting, different encodings, and all kind of operations. But when you interface with GLib and GStreamer, you receive char*<\/code> pointers from C APIs that are typically UTF-8 encoded and null-terminated. Converting back and forth between these and WebKit strings was often done in ad-hoc ways, sometimes creating unnecessary copies and sometimes not being very explicit about ownership.<\/p>\n

Another issue was encoding. WebKit internally works with different encodings (Latin1, UTF-16), but all the strings coming from GLib and GStreamer are UTF-8. There was no compile-time enforcement of this distinction, so it was easy to mix things up.<\/p>\n

At the beginning, using StringView<\/code> to handle these C strings was kind of enough. It had a rawCharacters<\/code> method that allowed us to just wrap the C string pointer and work with it, even though there was no way to enforce encoding correctness. It was not ideal, but it worked. Then WebKit began to move towards using spans and that is when the real problems popped up: spans carry a pointer and a size, but the size was not accounting for the null terminator. So when you wrapped a null-terminated C string into a span, the null terminator was left out, and if any code down the line relied on it being there, you had memory issues. This was the moment it became clear that we needed a proper type that understood null termination as a first-class concept.<\/p>\n

CStringView: a non-owning view of null-terminated UTF-8 strings<\/h2>\n

My first version of CStringView<\/code> was actually a bigger class. I had added many string operations as member functions: startsWith<\/code>, endsWith<\/code>, contains<\/code>, find<\/code>, case-insensitive comparisons… It felt natural to me as a developer \u2014 you go to the header of a class and you see everything you can do with it. But during the review of PR #51619<\/a>, Darin Adler made a very good point: CStringView<\/code> should only handle what makes it special, which is the null termination guarantee. All the other string operations should work on spans, because they do not depend on null termination and should not be duplicated for every string type. If you have a CStringView<\/code> named view<\/code>, you just write contains(view.span(), ...)<\/code> instead of view.contains(...)<\/code>. This way, the same functions work for any span of characters, and CStringView<\/code> stays small and focused. I was initially skeptical, but after writing the code I have to say he was right.<\/p>\n

So the final CStringView<\/code> is a lightweight, non-owning view over a null-terminated UTF-8 string. Think of it like std::string_view<\/code> but with two key differences: it guarantees null termination and it works with char8_t<\/code> instead of char<\/code>.<\/p>\n

class CStringView final {\n    \/\/ ...\n    static CStringView unsafeFromUTF8(const char* string);\n    static CStringView fromUTF8(std::span<const char8_t> spanWithNullTerminator);\n\n    const char* utf8() const;\n    size_t lengthInBytes() const;\n    std::span<const char8_t> span() const;\n    std::span<const char8_t> spanIncludingNullTerminator() const;\n    bool isEmpty() const;\n    bool isNull() const;\n};<\/code><\/pre>\n
Using char8_t<\/code> is important because it prevents mixing encodings at compile time. If you try to pass a char*<\/code> to something expecting char8_t<\/code>, the compiler will complain. This is exactly what we wanted: making encoding mismatches a compilation error rather than a runtime bug. This requirement came from Geoffrey Garen during earlier reviews to ensure we were not mixing Latin1 or UTF-16 with this class. You might have noticed the unsafeFromUTF8<\/code> factory method: the unsafe<\/code> prefix is a WebKit convention for APIs that deal with raw pointers without a known size. Since a bare const char*<\/code> has no size information, we have to trust the caller and compute the length with strlen<\/code>, which is inherently unsafe. The safe counterpart, fromUTF8<\/code>, takes a std::span<\/code> where the size is already known.<\/p>\n
CStringView<\/code> also has a utf8()<\/code> method that returns a plain const char*<\/code> for interfacing with C APIs that expect it. The class is designed to sit on the stack (heap allocation is forbidden) and it carries no overhead since it is essentially just a span.<\/p>\n
The work on making the span-based operations available in StringCommon<\/code> (Bug 299946<\/a>) involved improving the templates to support char8_t<\/code> spans, so that operations like startsWith<\/code>, endsWith<\/code>, contains<\/code>, find<\/code> and case-insensitive comparisons work seamlessly. Many of these methods were only templated for Latin1Character<\/code> and needed some tweaking to also accept char8_t<\/code>. On top of that, some of these functions accepted different character types for their different parameters, but we wanted to ensure that char8_t<\/code> was checked at compile time so that it could not be mixed with any other encoding-incompatible type. For example, comparing a UTF-8 code unit with a Latin1 character byte by byte is simply incorrect for non-ASCII characters, so the compiler should prevent you from doing it in the first place. These utility functions can be found in StringCommon.h<\/a> and StdLibExtras.h<\/a>.<\/p>\n
After the class was ready, I went through the GStreamer code and increased its use (Bug 299443<\/a>). This touched a significant amount of files across the WebRTC, media player, and media stream code, replacing raw const char*<\/code> juggling with proper CStringView<\/code> usage.<\/p>\n
If you ever need to convert a CStringView<\/code> into a String<\/code>, for example to supply it to a WebCore API, the proper way is straightforward: String newString = cStringView.span();<\/code>. The String<\/code> constructor that takes a std::span<const char8_t><\/code> handles the UTF-8 conversion correctly without needing any intermediate wrappers.<\/p>\n
For the opposite direction, converting a String<\/code> into a CStringView<\/code>, the path goes through CString<\/code>: you first call .utf8()<\/code> on the String<\/code> to get a CString<\/code> (which performs the encoding conversion), and then wrap it with CStringView::unsafeFromUTF8(cString.data())<\/code>. It is important to keep the CString<\/code> alive as long as the CStringView<\/code> is in use, since CStringView<\/code> does not own the data. That said, this kind of conversion is not common in practice. If you already have a String<\/code>, the logical step is to keep using it all the way to the end of the WebKit API onion and, when you finally need a const char*<\/code> for a C API, just call myString.utf8().data()<\/code>.<\/p>\n
GMallocString: an owning wrapper for GLib-allocated strings<\/h2>\n
The second piece was GMallocString<\/code> (Bug 303909<\/a>).<\/p>\n
Many GLib and GStreamer APIs return newly allocated strings that you must free with g_free()<\/code>. Before GMallocString<\/code>, we had GUniquePtr<char><\/code> for this, but it was just a raw pointer wrapper with no string-specific functionality. You could not easily compare it, convert it to a WebKit string, or even get its length without calling strlen<\/code> yourself.<\/p>\n
GMallocString<\/code> solves this by wrapping an owned, g_malloc-allocated, null-terminated UTF-8 string. It can adopt strings in several ways:<\/p>\n
\/\/ From a raw char* (takes ownership):\nauto str = GMallocString::unsafeAdoptFromUTF8(g_strdup(\"hello\"));\n\n\/\/ From a GUniquePtr<char>:\nGUniquePtr<char> gstr(g_strdup(\"world\"));\nauto str2 = GMallocString::unsafeAdoptFromUTF8(WTFMove(gstr));\n\n\/\/ Copy from a CStringView:\nGMallocString str3(myCStringView);<\/code><\/pre>\n
Once you have a GMallocString<\/code>, you get the same span()<\/code>, utf8()<\/code>, lengthInBytes()<\/code> interface as CStringView<\/code>. You can compare them with ==<\/code>, convert to CStringView<\/code> with toCStringView()<\/code>, and use them with safePrintfType<\/code> for safe logging. The class is move-only (no copies), which is the right semantics for an owning wrapper.<\/p>\n
The nice thing is that GMallocString<\/code> preserves the original null-terminated C string without performing any copy when adopting, and it frees it with g_free()<\/code> when it goes out of scope. This makes it a perfect fit for the GLib\/GStreamer interop pattern where you receive an allocated string and need to use it for a while before discarding it.<\/p>\n
The bigger picture<\/h2>\n
These two classes together cover the two main use cases for C string handling in our code:<\/p>\n