On 01 Dec 2013, at 01:33, Adrian Chadd <adrian_at_freebsd.org> wrote: > On 30 November 2013 15:25, Dimitry Andric <dim_at_freebsd.org> wrote: ... >> Basically, if you rely on undefined behavior, you are inventing your own >> de facto language, which is *not* C. That is fine with me, but let's >> not pretend the FreeBSD kernel is written in C then. :-) > > Are you able to have clang/llvm/gcc tell us where/when code is relying > on undefined behaviour? So we can, like, fix them? Not in the most general sense, since that would amount to solving the halting problem. But there are some tools that can help quite a lot. I guess Coverity can already cover quite a lot of cases, and there is also the STACK tool from MIT: http://css.csail.mit.edu/stack/ It would be really nice to have this in ports. Another mechanism is run-time detection, e.g. the undefined behavior sanitizer and other sanitizers: http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation some of which have also been ported to gcc, see: http://gcc.gnu.org/gcc-4.9/changes.html However, these have not been completely ported to FreeBSD yet, and come at a (sometimes large) run-time cost. Still a lot less than valgrind, though. :-) Also, for use in the kernel, the run-time support would have to be ported separately to the kernel environment. > If there was a way to lint this stuff then yes, please lint it. > > Otherwise we don't have the tools to know whether we're doing sane > things or not. > > (Same with things like strict aliasing..) Yes, the comparison with strict aliasing is spot-on. A lot of code has been written that is not aliasing safe, and if it is too much effort to fix it, using -fno-strict-aliasing is a reasonable workaround. Note this option can prevent a lot of very useful optimizations, but if you do not particularly care (for example if you are waiting for slow hardware anyway), it is fine to use it. -Dimitry
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC