Re: Trouble running Lua script from C++ application

["James Dennett" <james.dennett@...>]

On Sat, Jun 28, 2008 at 4:24 AM, David Given <dg@cowlark.com> wrote:
> James Dennett wrote:
> [...]
>> int f() {
>>   g();
>> }
>>
>> in the case where g() never returns normally (i.e., it terminates
>> execution or throws an exception).  Warning about f would be bad in
>> those cases, but failing to warn if g() ever does return is bad too,
>> and adding runtime checks is also bad (as it adds overhead).
>
> This is why most compilers have a way of declaring functions as 'does
> not return'.

I'm aware that some do; I doubt that it's most, but I don't have hard
numbers to back that up.

>
> extern void g(void);
> int f() { g(); }
>
> => test.c:2: warning: control reaches end of non-void function
>
> #define NORETURN __attribute__ ((__noreturn__))
> extern void g(void) NORETURN;
> int f() { g(); }
>
> => compiles cleanly. (This is with gcc. Other compilers will need
> different syntax, alas.)

Because there's no standard way to say that a function doesn't return,
indeed.  Filing a bug report against a compiler because it lacks an
*extension* which would enable it to more safely diagnose missing
return statements seems rather harsh; it's a feature request, if
anything.

There are other cases not involving function calls, of course (so I
regret picking the simplest case as my example).

int f() {
  while (g()) h()
}

might well happen to exist in a context (such as being created by a
macro) where g() always returns a "true" value.  In general, knowing
whether a function will fall-off the end means solving the halting
problem.  It's doable for many common cases, particularly with
compiler-specific extensions, but not across the board.  Manual
annotations carry some risk of being wrong (or becoming wrong during
maintenance).  That risk might be acceptable, or it might not,
depending on circumstances.

-- James