[libcxx-commits] [libcxx] [libc++][string] Replace ASAN volatile wrapper with memory barrier (PR #184693)
Nikolas Klauser via libcxx-commits
libcxx-commits at lists.llvm.org
Sat Apr 25 01:52:05 PDT 2026
philnik777 wrote:
> So I suspect short string annotation is flawed, maybe it has to be either make optional, or even disabled competently. Now it blocks us from having string annotations, because of false positives like this.
>
> As workaround maybe we could always allocate buffer if we enable string annotations. Not sure how this will affect abi. @philnik777
As I think about this more I tend to agree with this more and more. Here is my current understanding:
What the ASan container annotations do is claim that there is no pointer in the program that is allowed to dereference a particular part of memory. This works for global heap allocations and mostly works for custom allocators (except when you try to not run the destructor). What we're trying to claim with the SSO annotations is that the pointer returned by interfaces of `string` cannot dereference some parts of the object. However, that claim cannot be expanded to "there is _no_ pointer" for obvious reasons, so we can't actually express what we want to with the ASan container annotations. What we're lacking is an interface to say that certain pointers are only allowed to dereference N bytes. I don't know how feasible that would be for ASan, since you'd need to track that on a per-pointer basis, but at least for something like MSan it should be possible to track, since that's ABI unstably anyways AFAIK.
If you agree with my current understanding I think the most reasonable thing to do is to remove the fundamentally flawed annotations and try to introduce a `__builtin_(assume?)_dereferenceable_up_to(void* ptr, size_t offset)` to inform the compiler that a pointer can only access parts of the object. Such an annotation could possibly also be used by the compiler to improve alias analysis I think, though I don't know whether or not we want to mix the two.
Any thoughts?
https://github.com/llvm/llvm-project/pull/184693
More information about the libcxx-commits
mailing list