lua-users home
lua-l archive

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


Hi,

skaller wrote:
> In both cases, it only works with an idiomatic
> coding style -- eg don't put pointers to heap
> memory in local variables between throw
> and catch points, or you get a leak.

I think it would be sufficient to give specific rules to C/C++ programmers
about what they can and what they can't do. There are already rules
(like: encapsulate resources into userdata with GC methods) and the new
rules do not differ much from the old ones. Mainly because every call
to a Lua C API function is already a potential throw point (almost all of
them _may_ call lua_error() -> luaD_throw() one way or another).

> Lua should probably do this too, and thus get
> rid of pcall, or rather, get rid of the 
> setjmp/longjmp implementation of it.
> Unfortunately this would probably require a change
> in the CAPI protocol.. 
> 
> Does anyone have any idea how much?
> [I'm asking: what would change if error
> conditions were just passed up the stack]

A quick survey of the sources shows around a hundred places where the
core needs to be modified. Expect some slow-downs, too (because of all
the additional code needed to check for errors in upcalls and pass them on).

But the real problem is that the C API would break. Almost every C API
prototype must be changed to add error reporting. Almost all user-written
C functions need to be changed to explicitly check for these errors and
pass them on.

I'm not in favour of changing this. I can live with a few rules.

Bye,
     Mike