mstorsjo wrote: > The core reasoning is that asan is a "only one allowed per process" type > thing (you can't have one copy of the asan runtime handling a malloc while a > different one handles the corresponding free).
Not to distract from the direction taken here (which I do agree seems reasonable, even if I haven't had time to look closer at the PR yet) - but, when using the static CRT in general, doesn't the same concern apply there as well? I.e. when using the static CRT, care must be taken that the same CRT instances does frees as did the allocation. But I guess there are other asan-related aspects that makes it even more of a mess. Also secondly, when discussing these details - how the asan runtime is built in one, specific way, while it is used for applications that can use a different CRT configuration - would you like to chime in on https://github.com/microsoft/vcpkg/pull/34123#issuecomment-1760396486? There, some people involved questioned and weren't convinced that one part of a project (compiler-rt in llvm) should be allowed to override the CRT choice that is made for the whole vcpkg build. I tried to argue that compiler-rt is a very special case and doesn't interact with the rest of the libraries built in vcpkg like that, and compiler-rt is free to override the CRT to use internally. https://github.com/llvm/llvm-project/pull/81677 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
