Re: "noreturn" attribute in lua_error & Co

[William Ahern <william@...>]

On Thu, Apr 19, 2012 at 07:13:50AM -0500, Coda Highland wrote:
> >        I'm afraid to say it, but I think you are assuming what a programmer
> > might miss.
> >        There are languages where there is no explicit return, and with
> > explicit ones. There is also Pascal where you store the return in a special
> > variable (if memory still serves me well).
> >        It's really hard to say what would be beneficial to the programmer.
> > If you mean the "lua" programmer then I dunno, I myself started doodling
> > with it just year or so ago, after several years of not using it.
> 
> The general rule is "explicit is better than implicit."

The recent OpenSSL heap overflow argues to the contrary if we're talking
general rules. In that case the authors would have done well to rely on
implicit conversions (perhaps also using unsigned arithmetic), which would
have certainly mitigated the effect, and probably brought the issue to
people's attention through compiler warnings.

But this isn't really an explicit/implicit issue, because there's nothing
implicit about lua_error() returning, at least from the compiler's
perspective.

Specifying `return' isn't just good manners, it's almost a necessity,
otherwise a compiler could throw up warnings and errors if it does any kind
of flow analysis and suspects undefined object access.

C11 provides a _Noreturn function specifier, but for many reasons Lua's API
can't use this or its cousins. Therefore the C programmer is expected to
supplement the API with an explicit return, or otherwise suffer the
consequences of unspecified programmer behavior.