[pascal_cuoq]

> Doesn't "undefined behaviour" means that solution might not be portable?

It is only undefined behavior if you call the function with aliasing arguments, which is exactly what you are committing not to do anyway. It is only similar to writing the function in C99 with restrict and then calling it with aliasing pointers: you get garbage but it is your fault.

> Anyway it looks like a mess.

I actually wrote this blog post in reaction to the ongoing debate about the exploitation of undefined behavior by C compilers for optimization. As Tom Duff noted in other circumstances, “This code forms some sort of argument in that debate, but I'm not sure whether it's for or against.”

[krollew]

>I actually wrote this blog post in reaction to the ongoing debate about the exploitation of undefined behavior by C compilers for optimization.

So, it looks like they do quite good job. They noticed that there was some feature needed, provided with some workaround. They added it to standard. No workarounds needed anymore. Workaround that uses some compiler features, but in terms of programming language don't make any sense. That's great, makes C better with same, good sanity. In fact, one of best things I like C for. :)

[capisce]

> ongoing debate about the exploitation of undefined behavior by C compilers for optimization

Can you provide some links to other examples of this?

[pascal_cuoq]

There was much gnawing of teeth when compilers started to take advantage of the “strict aliasing rule”: http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-...

Programmers might think that it is okay to use uninitialized variables as a source of additional entropy (xoring with the real source of entropy), but it isn't, because the compiler will treat the uninitialized access as undefined behavior and eliminate code altogether: http://kqueue.org/blog/2012/06/25/more-randomness-or-less/

This 3-part blog post by Chris Lattner has various examples: http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

[rcfox]

http://blog.regehr.org/archives/767