lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am 21.10.2015 um 15:45 schröbte Viacheslav Usov:
On Tue, Oct 20, 2015 at 7:33 PM, Philipp Janda <> wrote:


You shouldn't throw exceptions from `extern "C"` functions, especially if
real C code is involved. So the whole point of compiling Lua as C++ becomes

This is false.  Oh, and "real C" is not defined, too.

"Real C" for the scope of this thread is defined (by me) as code compiled by a C compiler in contrast to an `extern "C"` function that is compiled by a C++ compiler. E.g. gcc by default does "The Right Thing" (`-fexceptions`) for C++ code, but not for C code. That's why I made the distinction. In theory it isn't needed, because the behavior is undefined by the C++ and C standards in both cases.

The current C++ standard states, in clause 7.5.1: "Some of the
properties associated with an entity with language linkage are
specific to each implementation and are not described here".
Subsequent clauses on language linkage do not introduce any
exception-related restrictions.

Meaning the C++ standard doesn't define those properties.

So exception propagation over C/C++ boundaries is both standard
compliant and entirely implementation specific.

Any C++ compiler/implementation is allowed to define behavior that is undefined by the C++ standard.


So if you have C code *and* C++ code, and both use `lua_CFunction`s, your
only standards compliant option is to compile Lua as C and use `extern "C"`
in your C++ code for your binding functions.

This is not the only option. One can still compile Lua as C++ with
lua_CFunction and other function types defined as extern "C".

`lua_pcall()` (C++) -> Lua code -> `lua_CFunction` (`extern "C"`) -> `lua_error()` (C++) -> `throw`. So we have undefined behavior again because the exception passes language boundaries. Whether it works in practice depends on compiler/implementation, command line flags, whether it's "real C" code the exception is passing through, etc.