On 01 Dec 2013, at 01:33, Adrian Chadd <adr...@freebsd.org> wrote:
> On 30 November 2013 15:25, Dimitry Andric <d...@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:


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:


some of which have also been ported to gcc, see:


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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to