[Scummvm-devel] Use of exceptions / setjmp in Lua

[Alex Bevilacqua]

This may or may not be helpful, but if you take a look at the CorsixTH
project (http://code.google.com/p/corsix-th/), they've implemented Lua
persistence without using Pluto, and it appears to be quite portable
(Win/OSX/Linux at least). I'm pretty sure they're implementation is specific
to their project, but if it's a viable option, it would allow you to drop
both Pluto and Lua as dependencies, as it wouldn't force you to maintain a
specific Lua version in trunk.

On Tue, Oct 19, 2010 at 7:18 AM, Max Horn <max at quendi.de> wrote:

> Hi there,
>
> I just saw bug report #3090234 "SWORD25: Code analysis warnings", and that
> pointed out the following issue (amongst others):
>
> d:\sources\scummvm\scummvm\engines\sword25\util\lua\ldo.cpp(118): warning
> C4611: interaction between '_setjmp' and C++ object destruction is
> non-portable
> This is not an analysis warning. It might need to be disabled in the
> property file when generating the project files with create_msvc if deemed
> invalid
>
> Looking at luaconf.h, it turns out that the Lua code indeed makes use of
> setjmp. That's rather bad news, as setjmp is not that portable. Instead of
> setjmp, Lua can apparently also use C++ exceptions -- something we have
> tried to avoid so far (and disabled in our build system). Still, I figure it
> might cause less harm to use those than to use setjmp. But either way, we'll
> have to deal with this.
>
> On the short run, we could get along by adding a setjmp configure check,
> and disabling the sword25 engine if setjmp is not present and working.
>
> On the long run, we could remove the Lua code again and rely on it being
> provided as an external dependency, which would be free to use setjmp or
> throw/catch.
>
> However, we then still would have the problem of pluto being tightly linked
> to the exact Lua version... However, note that from the pluto homepage <
> http://lua-users.org/wiki/PlutoLibrary>, though, it sounds as if any Lua
> 5.1.x version would be acceptable. Is that correct?
>
> Anyway, as I see it, pluto may have some other issues. For example, from
> some things I read while googling around, I got the impression that pluto
> does not store data in a platform independent way. Hence, sword25 savestates
> would not be portable across platforms, assuming they make use of pluto. If
> anybody knows more about this, then please chime in!
>
> The Pluto project also seems to be dormant (see e.g. this unhandled bug
> report about issues on 64bit systems: <
> http://luaforge.net/tracker/index.php?func=detail&aid=47527&group_id=31&atid=216
> >).
>
> There is a fork on github <http://github.com/hoelzro/pluto> which might be
> interesting to investigate, it even provide a roadmap. Well, and we could
> also simply try to contact the original Pluto author as well as the fork's
> author...
>
>
> Cheers,
> Max
>
>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20101019/ef1a96ba/attachment.html>