[libcxx-commits] [libcxx] [libc++] Improve aligned allocation support with picolibc. (PR #96086)

[Simon Tatham via libcxx-commits]

statham-arm wrote:

> If both allocators already have aligned allocation support, why can't the second one simply implement the posix interface?

By "simply", it sounds as if you mean "the picolibc maintainer should add an extra function, so that libc++ doesn't have to choose a working one of its existing `#ifdef` branches"?

I see that that's simple from the libc++ end, but if I took that idea to the picolibc project, I wouldn't be at all surprised to find them asking the same question in reverse – why can't libc++ "simply" use the working code it already has?

All the world's not POSIX. But all the world _is_ C, if you're implementing a C++ library. So, to my way of thinking, it's better to use functionality in the C standard than the POSIX standard if possible, and depend only on POSIX for things you can't do any other way. That's why I'm in favour of fixing this on the libc++ side.

In an application, it seems to me this wouldn't have been a question at all. If you're _linking_ programs, you don't have to keep a database of which C libraries have which functions; you'd just do a cmake test that finds out whether each function is there or not, and choose a `#ifdef` branch based directly on `HAVE_C11_ALIGNED_ALLOC` as output by the test you just did, rather than having to second-guess based on `__FOOLIBC_VERSION__` for an open-ended set of `FOO`.

I guess we can't reliably do checks of that kind in this context, or we'd already be doing it.

If you'd rather not complicate the ifdefs further, how about adding a manual configuration option to override them? That way, if I'm trying to build for a libc that libc++ doesn't know about, I can tell it on the cmake command line what functions that libc provides.

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