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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
