<div dir="ltr"><div dir="ltr">Three years ago when Chrome <a href="https://crbug.com/801780">switched</a> to llvm's STL even on Windows, the switch resulted in many advantages such as better crash reports as better call stack I think, being able to use new STL features consistently, enabling more of runtime sanitizers, etc.<div><br></div><div>When llvm libc project was announced I left <a href="https://twitter.com/ebraminio/status/1143628963106787328">this comment</a> in Twitter which ofc a full self contained libc won't be a possibility without having things as WASI but that's a different matter, yet, having access to more of libc perhaps can be useful to embed system of different kind.</div><div><br></div><div>Considering those, is llvm-libc use for Chrome on all its targets something expected to happen? I know the project is expected to be something stable in two years just that maybe my question helps on better planning for the project.</div><div><br></div><div>And as a side question, do you think a renterant qsort, qsort_r, is a possibility on llvm's libc? At least that can be used in <a href="https://source.chromium.org/chromium/chromium/src/+/master:third_party/boringssl/src/crypto/stack/stack.c;l=368-376?q=qsort_r&ss=chromium">BoringSSL</a> and <a href="https://source.chromium.org/chromium/chromium/src/+/master:third_party/swiftshader/third_party/llvm-subzero/include/llvm/ADT/STLExtras.h;l=423-432?q=qsort_r&ss=chromium">llvm's STL</a>. Maybe if there was a __builtin_qsort and __builtin_qsort_r with the capability those projects could benefit from it even sooner. Ofc that alone maybe isn't a good reason to make a popular library tied to a specific compiler but maybe as tiny motivation.</div></div></div>