https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
--- Comment #4 from Romain Geissler <romain.geissler at amadeus dot com> --- Thanks Richard. Indeed, beyond the false positive described in this bug, our whole code that implement "relative pointer" is I think quite hacky and not very compiler friendly (around alignment, aliasing rule, pointer arithmetic). We should review and update it a lot. Actually a similar class exists in Boost.Interprocess under the name "offset_ptr", and they did write this in their header: https://github.com/boostorg/interprocess/blob/develop/include/boost/interprocess/offset_ptr.hpp //Note: using the address of a local variable to point to another address //is not standard conforming and this can be optimized-away by the compiler. //Non-inlining is a method to remain illegal but correct //Undef BOOST_INTERPROCESS_OFFSET_PTR_INLINE_XXX if your compiler can inline //this code without breaking the library any time they need to deal with pointer to offset conversion, or vice-versa. I happens that we also suffer from similar problems and had to put attribute "noinline" "randomly" in places to "fix" (actually workaround our poor understanding of how the compiler works) problems we are seeing with the behavior of this library when compiled with optimizations. We should obviously review greatly in depths what we are doing which seems wrong in many places. PS Martin: I am ok to leave unresolved, just I think the wording of the error should be somehow updated so that the fact that it's only a possibility for not a certainty, other of your warnings around string management do print the range of value that gcc found out is possible, and that helps in understanding and fixing/silencing the warnings.
