Re: How does string.format handle undefined behavior?

[Roberto Ierusalimschy <roberto@...>]

> The whole mess of UB is just that: people thinks "most implementation won't
> do something silly in this case", then you find the "right" compiler
> switch, the "right" compiler version, the "right" DLL linked-in, the
> "right" C-lib version and some years down the road something goes horribly
> wrong.

If you follow this line up to its logical end, it becomes impossible
to program in C.

A small illustration: as far as I can find, the standard says nothing
about the possibility of a stack overflow due to too many pending
calls. There is no way to check it, there is no ensured minimum,
it is not defined as undefined, nothing. I see two ways to interpret
this.

Option 1: As the standard never mentions that a function call can
go wrong due to "stack overflow" (too many pending calls), then all
function calls should work as described, no matter how many pending
calls there are in the execution. As they don't, it follows that
all compilers we know about are badly buggy.

Option 2: We accept that the number of pending function calls have some
implicit limit, and once a program crosses that limit we have some
undefined behavior. As the standard does not set a minimum for this
limit (which does not even exist, according to the standard), it can be
be any value. A single call to 'printf' in helloword.c can legitimately
cause a stack overflow and therefore undefined behavior. (The standard
also offers no way to check this limit.) If we cannot accept UB, no
matter what, then we should never call any functions in our programs.
It doesn't matter that such calls always worked in all compilers
we ever used; some years down the road something can go horribly
wrong, and we have only ourselves to blame.

-- Roberto