[interprocess] Possible bug in offset_ptr
Hi, I reported a problem to the clang project about a problem I had with some release-compiled boost code. They're claiming it is a problem in offset_ptr, where the pointer arithmetic causes undefined behaviour according to the C++ standard. See: http://llvm.org/bugs/show_bug.cgi?id=10119 This seems like a fairly major thing, if it is true. Cheers Lars
El 20/06/2011 9:14, Lars Hagstrom escribió:
Hi,
I reported a problem to the clang project about a problem I had with some release-compiled boost code. They're claiming it is a problem in offset_ptr, where the pointer arithmetic causes undefined behaviour according to the C++ standard. See: http://llvm.org/bugs/show_bug.cgi?id=10119
This seems like a fairly major thing, if it is true.
It is true, yes, it always has been outside the standard, but worked for all compilers. For aggressive optimizers, the only solution is to disable inlining so that the compiler is forced to create stack offset_ptr variables with real addresses, that's the solution I took in trunk. Windows compilers had this inlining disabled since ages (__declspec(noinline)) and GCC was recently added (__attribute__((noinline))). The fact is that with current standard, relative addressing is banned and I don't think there is workaround at all inside the standard. I think shared memory containers are not possible without visiting undefined behaviour. Best, Ion
Right! I tried my test code with boost trunk, and it works now! It seems that clang defines __GNUC__, and therefore uses the newly added noinline code. Thanks for the info! (And the fix that you'd already made...) /Lars 2011/6/20 Ion Gaztañaga <igaztanaga@gmail.com>
El 20/06/2011 9:14, Lars Hagstrom escribió:
Hi,
I reported a problem to the clang project about a problem I had with some release-compiled boost code. They're claiming it is a problem in offset_ptr, where the pointer arithmetic causes undefined behaviour according to the C++ standard. See: http://llvm.org/bugs/show_bug.**cgi?id=10119<http://llvm.org/bugs/show_bug.cgi?id=10119>
This seems like a fairly major thing, if it is true.
It is true, yes, it always has been outside the standard, but worked for all compilers. For aggressive optimizers, the only solution is to disable inlining so that the compiler is forced to create stack offset_ptr variables with real addresses, that's the solution I took in trunk. Windows compilers had this inlining disabled since ages (__declspec(noinline)) and GCC was recently added (__attribute__((noinline))).
The fact is that with current standard, relative addressing is banned and I don't think there is workaround at all inside the standard. I think shared memory containers are not possible without visiting undefined behaviour.
Best,
Ion ______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
participants (2)
-
Ion Gaztañaga -
Lars Hagstrom