https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103162
--- Comment #7 from Florin Iucha <florin.iucha at amd dot com> --- That is most unfortunate because it will force us to duplicate the library used for resource management. Not only that, but if I were to implement the pmr::memory_resource interface in terms of the other library which returns uintptr_t/size_t (including the occasional 0), I would have to pay an additional virtual method call just to wrap a static_cast / bit_cast. 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. Also -fno-delete-null-pointer-checks is not helping me (I mistakenly thought it silenced the sanitizer) because I am not directly dereferencing the result. However the error I am getting is when I run the undefined behavior sanitizer and it notices that the values returned from allocate() (retrieved from my do_allocate) or passed back to deallocate() violate the attributes. So I am left with three unsavory choices: 1. patch the standard library to remove the checks; 2. do not run undefined behavior sanitizer, or figure out some way to distribute suppression files with the binaries; 3. internally fork the libraries, with one flavor to be used with real memory and real objects, the other with abstract "address ranges", and delegate one implementation to the other, paying an extra virtual method call.
