https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Florin Iucha from comment #7) > There are uses for the memory_resources pattern, outside of its current > application in the standard library - for example allocating ranges in a > file, or in a shared memory segment. 0 is valid allocation, although > obviously not directly dereferenceable. Well then it's not a valid use of pmr::memory_resource. It needs to return a pointer to dereferenceable memory (after casting it from void* to something else of course). If you have a scenario where you are doing some additional step to convert the returned value into a dereferenceable pointer, can't you just adjust the returned values to make that work? e.g. set the most significant bit in the returned value, and clear it when converting it to a pointer, or add a constant offset to every returned value and then subtract that again when converting it to a pointer. If you're abusing the pmr::memory_resource interface to return a uintptr_t disguised a a void*, well that's abusing the API and not intended to be supported (according to the author of the proposal that added it to C++).
