lua-users home
lua-l archive

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

It was thus said that the Great Coda Highland once stated:
> On Sat, Feb 24, 2018 at 9:33 PM, Soni "They/Them" L. <> wrote:
> > Lua's C API is not idiomatic. I don't see setjmp/longjmp used by things like
> > POSIX (as far as I know nothing in POSIX says you have to use setjmp/longjmp
> > to handle errors) or libuv.
> >
> > It would be more idiomatic to return error codes, and have the caller
> > propagate errors. (Using setjmp/longjmp internally is fine tho.)
> >
> > This would also increase compatibility with some libraries and programming
> > languages.
> It is, as is the case with so many things, a tradeoff.
> setjmp/longjmp is faster at runtime and simpler to code. It does of
> course have a lot of limitations you have to be careful with, but
> error codes also have a lot of things you have to be careful with --
> among other things, using error codes implies using out parameters,
> which is pretty smelly in its own right.

  True.  I've only used setjmp()/longjmp() once [1] in over 25 years of C
coding and it saved a ton of code and simplified the design (otherwise, it
was over 500 instances of "rc = internalfunction(); if (rc != 0) return rc;"
and a more complex design).  I even turned it into a Lua module and the use
of setjmp()/longjmp() in both my code and Lua never caused an issue.

> Certainly the compatibility note is, well, noteworthy. But it doesn't
> seem to be worth the cost of refactoring the entire Lua codebase and
> API (thereby breaking literally every single C extension ever written)
> to accomplish that when you can write API wrappers to adapt Lua to
> work in the other environments (possibly using C++ mode).

  Well, Soni is certainly free to do the work and see how well it goes.


	It's an MC6809 CPU emulator as a library.