lua-users home
lua-l archive

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


Perhaps tangential to the discussion, but longjmp / setjmp has bitten me a lot too. From not running C++ destructors to making cleanup code get skipped and generally surprising behavior, if there's any mechanism I'd avoid in any API -- even with plain C where destructors and stack unwinding isn't a thing -- it's these.

Unfortunately, that means your entire API has to be rewritten from the ground up to propagate errors properly to every external function, meaning the internals have to be written to handle it. This is its own challenge, and is extremely hard to do properly throughout an entire API.

On Sun, Feb 18, 2018 at 9:06 PM, Soni "They/Them" L. <fakedme@gmail.com> wrote:


On 2018-02-18 11:03 PM, Andrew Gierth wrote:
"Soni" == Soni \"They/Them\" L <fakedme@gmail.com> writes:
  Soni> It was recently brought to my attention that the Lua C API is
  Soni> strictly a C API, and not as universal as some ppl claim it to
  Soni> be.[1]
  Soni> [1]: https://github.com/chucklefish/rlua/issues/71

This issue isn't really about C vs non-C, it's about longjmp
compatibility with the surrounding environment, which can be an issue
even with pure C code. (In embedding Lua in Postgres, which is a pure C
project, I also have this problem since Postgres has its _own_
setjmp/longjmp exception system, and hilarity ensues if you throw lua
errors across pg catch blocks or pg errors across Lua catch blocks.)

Like it or not, longjmp is part of standard C.


It's called "use setjmp/longjmp internally, but don't leak it across API boundaries".


--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.