[clang] clang_EvalResult_getAsCXString impl (PR #134551)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 15 10:36:13 PDT 2025


AaronBallman wrote:

> > What if we add unsigned clang_getCStringLength(CXString); which gets the length but not the contents? Do we need to package pointer and size together?
> 
> Where do we store the length, if we can't add a new field to `CXString`, and we can't use `private_flags` to store it?

I wasn't thinking of storing it at all, but I lost sight of the original goal which is to have strings with null bytes embedded in them, so storage really is critical for strings that aren't backed by a `CXStringBuf`.

I would *really* like to avoid coming up with a second string interface, but I kind of wonder if we're bumping up against that. `CXString` is passed by value everywhere, so we can't steal a flag in `private_flags` to mean "there's trailing data". And we don't really want to steal the all of the space for flags, but we also don't want to artificially limit the amount of text a `CXString` can represent, either.

I wonder if the way around this is: `createDup()` always creates a `CXStringBuf` and uses that? We effectively get rid of `CXS_Malloc`, and now we're always tracking the length for anything not created via a `const char *` (which we don't need to track length for because that form cannot have embedded nulls).

https://github.com/llvm/llvm-project/pull/134551


More information about the cfe-commits mailing list