Possibly Pythonic Tail Call Optimization (TCO/TRE)

[Steven D'Aprano]

On Wed, 15 Jul 2015 03:43 am, Marko Rauhamaa wrote:

> The problem there is in the C standard, not the compiler that complies
> with the standard.
> 
> I don't like the way integer overflows are explicitly undefined in
> modern C.
> 
> Similarly, I don't like the way tail call behavior is undefined in
> Python.

Tail call behaviour is not undefined in Python. There is a strong convention
(followed by all implementations I know of) to follow the reference
implementation's (CPython) behaviour, which is not to optimize tail calls.
But even if an implementation chooses to not follow that, it's not
*undefined behaviour*. It's just implementation-dependent behaviour.

No Python compiler is permitted to format your hard drive because you
perform a tail call.


> Neither blemish gives me much trouble in practice.

Given how even the best, cleverest, and most security conscious C
programmers get repeatedly bitten by C undefined behaviour, I'm confident
that if you've written any non-trivial C code, it almost certainly has bugs
because of undefined behaviour, you've just never noticed them yet. Perhaps
the specific version of the compiler you use doesn't optimize that case, or
you've never tried it with data that exposes the introduced bugs.


"Making the landmine a much much worse place to be is the fact that there is
no good way to determine whether a large scale application is free of
undefined behavior, and thus not susceptible to breaking in the future.
There are many useful tools that can help find some of the bugs, but
nothing that gives full confidence that your code won't break in the
future."

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html


So, if you make it a habit to religiously compile your C applications with
all warnings turned on, and you actually read *and fix* them all, AND you
scan the applications with Valgrind, the Clang static analyser, and
whatever other tools you can find, then you *might* have good reason to be
reasonably confident that your code is *mostly* free of C undefined
behaviour bugs.



-- 
Steven