Lua 5.3 and C++ exceptions

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua 5.3 and C++ exceptions

Colin Hirsch
Hi,

following the announcement of Lua 5.3 with the greatly appreciated addition of native integer support we are planning to update a bunch of C++ projects from Lua 5.1 and were wondering how the compatibility with C++ exceptions has progressed.


The scenario that we are looking at is

C++ application
calls
Lua function
calls
C++ function

when the inner C++ function throws an exception.


Currently we handle this situation at the Lua-to-C++ call point by wrapping the C++ function in a try-catch block that logs an exception and calls the Lua error function; at the C++-to-Lua transition we detect the Lua error and then throw a C++ exception.

(With C++11 we could improve this approach by extending the Lua state by a std::exception_ptr, storing the exception caught at the Lua-to-C++ transition there, and re-throwing it at the C++-to-Lua point.)


The question is, can this be simplified?

Ideally the C++ exception would simply “fly through” the Lua interpreter from the inner C++ function to the outside C++ application, but as far as I understand, that is not, or at least: was not possible because Lua obviously can’t use RAII and requires an explicit call to its error handling facilities to keep everything consistent.

If this “flying through” does not work unmodified, is it possible to somehow “patch up” things, i.e. let the exception fly through and then afterwards, in a try-catch at the C++-to-Lua point, call some Lua function to put things back into a consistent state? (This would allow leaving out the try-catch around the inner C++ function and not require adding the exception_ptr to the Lua state to recover the original exception.)

Or what else is the recommended way of handling this interoperability question, what is the current “best practice”?

Thanks, Colin


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Nagaev Boris
On Fri, Mar 13, 2015 at 9:23 AM, Colin <[hidden email]> wrote:

> Hi,
>
> following the announcement of Lua 5.3 with the greatly appreciated addition of native integer support we are planning to update a bunch of C++ projects from Lua 5.1 and were wondering how the compatibility with C++ exceptions has progressed.
>
>
> The scenario that we are looking at is
>
> C++ application
> calls
> Lua function
> calls
> C++ function
>
> when the inner C++ function throws an exception.
>
>
> Currently we handle this situation at the Lua-to-C++ call point by wrapping the C++ function in a try-catch block that logs an exception and calls the Lua error function; at the C++-to-Lua transition we detect the Lua error and then throw a C++ exception.
>
> (With C++11 we could improve this approach by extending the Lua state by a std::exception_ptr, storing the exception caught at the Lua-to-C++ transition there, and re-throwing it at the C++-to-Lua point.)
>
>
> The question is, can this be simplified?
>
> Ideally the C++ exception would simply “fly through” the Lua interpreter from the inner C++ function to the outside C++ application, but as far as I understand, that is not, or at least: was not possible because Lua obviously can’t use RAII and requires an explicit call to its error handling facilities to keep everything consistent.
>
> If this “flying through” does not work unmodified, is it possible to somehow “patch up” things, i.e. let the exception fly through and then afterwards, in a try-catch at the C++-to-Lua point, call some Lua function to put things back into a consistent state? (This would allow leaving out the try-catch around the inner C++ function and not require adding the exception_ptr to the Lua state to recover the original exception.)
>
> Or what else is the recommended way of handling this interoperability question, what is the current “best practice”?
>
> Thanks, Colin
>
>

Hello, Colin,

LuaJIT [1] can handle C++ exceptions transparently in some setups. C++
exceptions can be caught on the Lua side with pcall(), lua_pcall()
etc. It's safe to throw C++ exceptions across non-protected Lua frames
on the C stack. The contents of the C++ exception object pass through
unmodified. Throwing Lua errors across C++ frames is safe. C++
destructors will be called [2]. LuaJIT is compatible with Lua 5.1.

 [1] http://luajit.org/luajit.html
 [2] http://luajit.org/extensions.html#exceptions



Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Eric Wing
In reply to this post by Colin Hirsch
On 3/13/15, Colin <[hidden email]> wrote:

> Hi,
>
> following the announcement of Lua 5.3 with the greatly appreciated addition
> of native integer support we are planning to update a bunch of C++ projects
> from Lua 5.1 and were wondering how the compatibility with C++ exceptions
> has progressed.
>
>
> The scenario that we are looking at is
>
> C++ application
> calls
> Lua function
> calls
> C++ function
>
> when the inner C++ function throws an exception.
>
>
> Currently we handle this situation at the Lua-to-C++ call point by wrapping
> the C++ function in a try-catch block that logs an exception and calls the
> Lua error function; at the C++-to-Lua transition we detect the Lua error and
> then throw a C++ exception.
>
> (With C++11 we could improve this approach by extending the Lua state by a
> std::exception_ptr, storing the exception caught at the Lua-to-C++
> transition there, and re-throwing it at the C++-to-Lua point.)
>
>
> The question is, can this be simplified?
>
> Ideally the C++ exception would simply "fly through" the Lua interpreter
> from the inner C++ function to the outside C++ application, but as far as I
> understand, that is not, or at least: was not possible because Lua obviously
> can't use RAII and requires an explicit call to its error handling
> facilities to keep everything consistent.
>
> If this "flying through" does not work unmodified, is it possible to somehow
> "patch up" things, i.e. let the exception fly through and then afterwards,
> in a try-catch at the C++-to-Lua point, call some Lua function to put things
> back into a consistent state? (This would allow leaving out the try-catch
> around the inner C++ function and not require adding the exception_ptr to
> the Lua state to recover the original exception.)
>
> Or what else is the recommended way of handling this interoperability
> question, what is the current "best practice"?
>
> Thanks, Colin
>

So I think the expected practice is to compile Lua's ldo.c as C++. It
will define Lua's internal mechanism for pcall to use try/catch
instead of setjmp/longjmp. Then if a C++ exception does occur, pcall
will be aware of it and catch it and then you just do the normal error
handling thing. No need to do anything elaborate.

It looks like this was isolated to just ldo.c in Lua 5.3 (and 5.2?)
whereas it was in luaconf.h in Lua 5.1. Thank you to the Lua team for
this as somebody who had to modify this to work with Obj-C's exception
handling mechanism. I think this will make it much easier to
modify/maintain in the future.

-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Colin Hirsch
In reply to this post by Nagaev Boris

> On 13 Mar 2015, at 12:43, Nagaev Boris <[hidden email]> wrote:
>
> On Fri, Mar 13, 2015 at 9:23 AM, Colin <[hidden email]> wrote:
>> Hi,
>>
>> following the announcement of Lua 5.3 with the greatly appreciated addition of native integer support we are planning to update a bunch of C++ projects from Lua 5.1 and were wondering how the compatibility with C++ exceptions has progressed.
>>
>>
>> The scenario that we are looking at is
>>
>> C++ application
>> calls
>> Lua function
>> calls
>> C++ function
>>
>> when the inner C++ function throws an exception.
>>
>>
>> Currently we handle this situation at the Lua-to-C++ call point by wrapping the C++ function in a try-catch block that logs an exception and calls the Lua error function; at the C++-to-Lua transition we detect the Lua error and then throw a C++ exception.
>>
>> (With C++11 we could improve this approach by extending the Lua state by a std::exception_ptr, storing the exception caught at the Lua-to-C++ transition there, and re-throwing it at the C++-to-Lua point.)
>>
>>
>> The question is, can this be simplified?
>>
>> Ideally the C++ exception would simply “fly through” the Lua interpreter from the inner C++ function to the outside C++ application, but as far as I understand, that is not, or at least: was not possible because Lua obviously can’t use RAII and requires an explicit call to its error handling facilities to keep everything consistent.
>>
>> If this “flying through” does not work unmodified, is it possible to somehow “patch up” things, i.e. let the exception fly through and then afterwards, in a try-catch at the C++-to-Lua point, call some Lua function to put things back into a consistent state? (This would allow leaving out the try-catch around the inner C++ function and not require adding the exception_ptr to the Lua state to recover the original exception.)
>>
>> Or what else is the recommended way of handling this interoperability question, what is the current “best practice”?
>>
>> Thanks, Colin
>
> Hello, Colin,
>
> LuaJIT [1] can handle C++ exceptions transparently in some setups. C++
> exceptions can be caught on the Lua side with pcall(), lua_pcall()
> etc. It's safe to throw C++ exceptions across non-protected Lua frames
> on the C stack. The contents of the C++ exception object pass through
> unmodified. Throwing Lua errors across C++ frames is safe. C++
> destructors will be called [2]. LuaJIT is compatible with Lua 5.1.
>
> [1] http://luajit.org/luajit.html
> [2] http://luajit.org/extensions.html#exceptions

That does look interesting, although we’d have to check whether it is possible for us to switch to LuaJIT. The last time I looked at it that was not possible for lack of 64bit integer support (unfortunately Lua’s default numeric type “double” is not at all appropriate to our applications, and our Lua 5.1 is configured to use int64_t instead, something that Lua is well designed to handle). However it seems that in the meantime LuaJIT has gained support for some boxed 64bit integers, which might be good enough if well integrated…

Thanks again, Colin


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Colin Hirsch
In reply to this post by Eric Wing

> On 13 Mar 2015, at 13:58, Eric Wing <[hidden email]> wrote:
>
> On 3/13/15, Colin <[hidden email]> wrote:
>> Hi,
>>
>> following the announcement of Lua 5.3 with the greatly appreciated addition
>> of native integer support we are planning to update a bunch of C++ projects
>> from Lua 5.1 and were wondering how the compatibility with C++ exceptions
>> has progressed.
>>
>>
>> The scenario that we are looking at is
>>
>> C++ application
>> calls
>> Lua function
>> calls
>> C++ function
>>
>> when the inner C++ function throws an exception.
>>
>>
>> Currently we handle this situation at the Lua-to-C++ call point by wrapping
>> the C++ function in a try-catch block that logs an exception and calls the
>> Lua error function; at the C++-to-Lua transition we detect the Lua error and
>> then throw a C++ exception.
>>
>> (With C++11 we could improve this approach by extending the Lua state by a
>> std::exception_ptr, storing the exception caught at the Lua-to-C++
>> transition there, and re-throwing it at the C++-to-Lua point.)
>>
>>
>> The question is, can this be simplified?
>>
>> Ideally the C++ exception would simply "fly through" the Lua interpreter
>> from the inner C++ function to the outside C++ application, but as far as I
>> understand, that is not, or at least: was not possible because Lua obviously
>> can't use RAII and requires an explicit call to its error handling
>> facilities to keep everything consistent.
>>
>> If this "flying through" does not work unmodified, is it possible to somehow
>> "patch up" things, i.e. let the exception fly through and then afterwards,
>> in a try-catch at the C++-to-Lua point, call some Lua function to put things
>> back into a consistent state? (This would allow leaving out the try-catch
>> around the inner C++ function and not require adding the exception_ptr to
>> the Lua state to recover the original exception.)
>>
>> Or what else is the recommended way of handling this interoperability
>> question, what is the current "best practice"?
>>
>> Thanks, Colin
>
> So I think the expected practice is to compile Lua's ldo.c as C++. It
> will define Lua's internal mechanism for pcall to use try/catch
> instead of setjmp/longjmp. Then if a C++ exception does occur, pcall
> will be aware of it and catch it and then you just do the normal error
> handling thing. No need to do anything elaborate.

That makes sure that Lua doesn’t end up in an inconsistent state, but it doesn’t solve the bigger issue:

With a "outer C++ calls Lua calls inner C++" call-chain you really want the outer C++ to be able to catch the exception thrown by the inner C++ function.

Regards, Colin


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Roberto Ierusalimschy
In reply to this post by Colin Hirsch
> That does look interesting, although we’d have to check whether it
> is possible for us to switch to LuaJIT. The last time I looked at it
> that was not possible for lack of 64bit integer support (unfortunately
> Lua’s default numeric type “double” is not at all appropriate
> to our applications, and our Lua 5.1 is configured to use int64_t
> instead, something that Lua is well designed to handle). However it
> seems that in the meantime LuaJIT has gained support for some boxed
> 64bit integers, which might be good enough if well integrated…

(Out of topic) Can you give a brief explanation about why you need
64bit integer support? (I am writing something about the introduction
of integers in Lua 5.3, and it would be good to have some more concrete
examples of why people need 64bit integers.)

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Colin Hirsch
> On 13 March 2015 at 16:21 Roberto Ierusalimschy <[hidden email]> wrote:
>
> > That does look interesting, although we’d have to check whether it
> > is possible for us to switch to LuaJIT. The last time I looked at it
> > that was not possible for lack of 64bit integer support (unfortunately
> > Lua’s default numeric type “double” is not at all appropriate
> > to our applications, and our Lua 5.1 is configured to use int64_t
> > instead, something that Lua is well designed to handle). However it
> > seems that in the meantime LuaJIT has gained support for some boxed
> > 64bit integers, which might be good enough if well integrated…
>
> (Out of topic) Can you give a brief explanation about why you need
> 64bit integer support? (I am writing something about the introduction
> of integers in Lua 5.3, and it would be good to have some more concrete
> examples of why people need 64bit integers.)

We have multiple places where 32bit integers are not sufficient, for example time values (think microseconds since 1970), some
statistics where 32bits can easily overflow, and some network protocols that we access from Lua have 64bit integer fields.

(And while some of these integer use cases could fit into 64bit floating point variables, we really don't want to start using
floating point to model integer values, in particular in an application that doesn't use floating point anywhere else.)

After give-or-take a decade of working on 64bit machines I don't even want to think about whether something fits into 32bits :-)


Now regarding my initial question, do you have any intuition regarding how much is missing for making Lua exception safe? Is it just
some small detail that could be fixed with a small change, or does it require extensive reworking?

I have studied the Lua source code on various occasions, and successfully changed a few things, but haven't grokked some of the
overall concepts sufficiently well to answer this question myself.

Thanks, Colin

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Ahmed Charles
In my experience, compiling lua as C++ is sufficient to make it exception safe. Exceptions and setjmp/longjmp require the same considerations with regard to cleaning up resources.

Besides, this should be fairly easy to test/verify.


On Mar 13, 2015, at 2:03 PM, Colin Hirsch <[hidden email]> wrote:

>> On 13 March 2015 at 16:21 Roberto Ierusalimschy <[hidden email]> wrote:
>>
>>> That does look interesting, although we’d have to check whether it
>>> is possible for us to switch to LuaJIT. The last time I looked at it
>>> that was not possible for lack of 64bit integer support (unfortunately
>>> Lua’s default numeric type “double” is not at all appropriate
>>> to our applications, and our Lua 5.1 is configured to use int64_t
>>> instead, something that Lua is well designed to handle). However it
>>> seems that in the meantime LuaJIT has gained support for some boxed
>>> 64bit integers, which might be good enough if well integrated…
>>
>> (Out of topic) Can you give a brief explanation about why you need
>> 64bit integer support? (I am writing something about the introduction
>> of integers in Lua 5.3, and it would be good to have some more concrete
>> examples of why people need 64bit integers.)
>
> We have multiple places where 32bit integers are not sufficient, for example time values (think microseconds since 1970), some
> statistics where 32bits can easily overflow, and some network protocols that we access from Lua have 64bit integer fields.
>
> (And while some of these integer use cases could fit into 64bit floating point variables, we really don't want to start using
> floating point to model integer values, in particular in an application that doesn't use floating point anywhere else.)
>
> After give-or-take a decade of working on 64bit machines I don't even want to think about whether something fits into 32bits :-)
>
>
> Now regarding my initial question, do you have any intuition regarding how much is missing for making Lua exception safe? Is it just
> some small detail that could be fixed with a small change, or does it require extensive reworking?
>
> I have studied the Lua source code on various occasions, and successfully changed a few things, but haven't grokked some of the
> overall concepts sufficiently well to answer this question myself.
>
> Thanks, Colin
>
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Eric Wing
In reply to this post by Colin Hirsch
>> So I think the expected practice is to compile Lua's ldo.c as C++. It
>> will define Lua's internal mechanism for pcall to use try/catch
>> instead of setjmp/longjmp. Then if a C++ exception does occur, pcall
>> will be aware of it and catch it and then you just do the normal error
>> handling thing. No need to do anything elaborate.
>
> That makes sure that Lua doesn't end up in an inconsistent state, but it
> doesn't solve the bigger issue:
>
> With a "outer C++ calls Lua calls inner C++" call-chain you really want the
> outer C++ to be able to catch the exception thrown by the inner C++
> function.
>

Sorry, I got confused about the intent.  I think your rethrow idea
sounds best. Maybe modifying ldo.c to centralize this for you would be
ideal.


-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Eric Wing
In reply to this post by Roberto Ierusalimschy
On 3/13/15, Roberto Ierusalimschy <[hidden email]> wrote:

>> That does look interesting, although we'd have to check whether it
>> is possible for us to switch to LuaJIT. The last time I looked at it
>> that was not possible for lack of 64bit integer support (unfortunately
>> Lua's default numeric type "double" is not at all appropriate
>> to our applications, and our Lua 5.1 is configured to use int64_t
>> instead, something that Lua is well designed to handle). However it
>> seems that in the meantime LuaJIT has gained support for some boxed
>> 64bit integers, which might be good enough if well integrated...
>
> (Out of topic) Can you give a brief explanation about why you need
> 64bit integer support? (I am writing something about the introduction
> of integers in Lua 5.3, and it would be good to have some more concrete
> examples of why people need 64bit integers.)
>
> -- Roberto
>


For me, it was because APIs used 64-bit integers and I was binding Lua
directly to these APIs. In OS X/Cocoa, the move to native 64-bit began
seriously in 2007 with 10.5. (For context: Remember that Apple had
just migrated from PowerPC to Intel. I believe there was only one
32-bit only Intel Mac sold, the very first cheapest Mac Mini which was
discontinued in 2006. So there was never a large legacy base holding
native 64-bit back from being adopted. And the major improvements to
Objective-C 2.0 wanted to make breaking ABI changes, so Apple made
those available to 64-bit only since there was no 64-bit Cocoa prior
to 10.5 so there was nothing to break. Hence developers moved to
64-bit quickly.)

The basic integer everything uses in Cocoa is NSInteger which is
#define'd to long. So on 64-bit architectures, it is a full blown
64-bit quantity.

Here is NSMutableArray's API to remove an element from the array as an example:
- (void)removeObjectAtIndex:(NSUInteger)index;
Imagine hundreds or thousands of Cocoa APIs that use NSInteger and
NSUInteger just like this one.

Every API in Cocoa that uses an integer needs a 64-bit integer under
64-bit architectures.  Binding these to Lua was problematic with only
a double available.

You might get away with it if you don't need the higher bits, but some
constants throw a monkey wrench into this. For example, I think some
enums define the last value in the enum as NSIntegerMax or
NSIntegerMin. (I think to denote an error, out-of-bounds, or
undefined/null value.) So if you need to compare your value to those
constants, your comparison gives the incorrect results.


-Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Roberto Ierusalimschy
In reply to this post by Colin Hirsch
> Now regarding my initial question, do you have any intuition regarding how much is missing for making Lua exception safe? Is it just
> some small detail that could be fixed with a small change, or does it require extensive reworking?

IIRC, if you compile Lua as C++ code, you should be careful when
"mixing" your own exceptions with Lua errors.

I am not sure what you mean by "exception safe". If you mean throwing
your own exceptions anywehre inside Lua and catching them anywhere
else, there is a lot missing. For instance, in the following code

  try {
    ...
    lua_call(...);
    ...
   } catch ...

an exception inside 'lua_call' will leave the Lua state in a mess.

For instance, a protected call in Lua will catch any exception inside
it; so, you should not throw to it exceptions in points where a Lua
error could not naturally occurr (e.g., inside the allocation function).

Similarly, any exception thrown by Lua (in an error or yield) expects
that Lua will catch that exception to correct its internal state.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Colin Hirsch
In reply to this post by Roberto Ierusalimschy
> On 13 March 2015 at 16:21 Roberto Ierusalimschy <[hidden email]> wrote:
>
> > That does look interesting, although we’d have to check whether it
> > is possible for us to switch to LuaJIT. The last time I looked at it
> > that was not possible for lack of 64bit integer support (unfortunately
> > Lua’s default numeric type “double” is not at all appropriate
> > to our applications, and our Lua 5.1 is configured to use int64_t
> > instead, something that Lua is well designed to handle). However it
> > seems that in the meantime LuaJIT has gained support for some boxed
> > 64bit integers, which might be good enough if well integrated…
>
> (Out of topic) Can you give a brief explanation about why you need
> 64bit integer support? (I am writing something about the introduction
> of integers in Lua 5.3, and it would be good to have some more concrete
> examples of why people need 64bit integers.)

On a related note, we are currently considering upgrading from Lua 5.1 to Lua 5.2, rather than 5.3, because we _only_ need 64bit
integers, and 5.2 can be configured to use them exclusively, just like the 5.1 we are currently using.

We will of course first look into whether the floating point part of 5.3 can be safely and easily ignored in our use cases; our
concern is that the implicit conversion form integer to float might strike at inconvenient times...

...and we had already removed the implicit conversion or coercion from strings to integers from our version of Lua 5.1 because we
are not great friends of implicit type conversions of this kind.

Regards, Colin

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Nagaev Boris
On Sun, Mar 15, 2015 at 1:50 PM, Colin Hirsch <[hidden email]> wrote:
> ...and we had already removed the implicit conversion or coercion from strings to integers from our version of Lua 5.1 because we
> are not great friends of implicit type conversions of this kind.

Can you share this patch, please?

Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Roberto Ierusalimschy
In reply to this post by Roberto Ierusalimschy
> > I am not sure what you mean by "exception safe". If you mean throwing
> > your own exceptions anywehre inside Lua and catching them anywhere
> > else [...].
>
> Yes, that would have been ideal! Thanks for the definite
> clarification, even if not the answer we were hoping for. I'm also
> assuming that making Lua fully exception safe requires more than just
> a few small changes...

Yes. The design of Lua is all around the concept of "protected calls"
(and, by implication, of unprotected calls). Several pieces of code in
Lua assume that someone else (the protected call) will clear its mess
if an exception occurrs. To make Lua "exception safe" in that general
sense, you would have to correct all those places that do "unprotected
calls", which are many and hard to find.

(To be honest, I think the real difficulty is finding the correct places
to correct and then testing the result, as any non-corrected place is a
source of a hard-to-find bug. Maybe the size of the change is not that
big after all, I really have no idea.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Colin Hirsch
> On 15 March 2015 at 16:02 Roberto Ierusalimschy <[hidden email]> wrote:
>
> Yes. The design of Lua is all around the concept of "protected calls"
> (and, by implication, of unprotected calls). Several pieces of code in
> Lua assume that someone else (the protected call) will clear its mess
> if an exception occurrs. To make Lua "exception safe" in that general
> sense, you would have to correct all those places that do "unprotected
> calls", which are many and hard to find.
>
> (To be honest, I think the real difficulty is finding the correct places
> to correct and then testing the result, as any non-corrected place is a
> source of a hard-to-find bug. Maybe the size of the change is not that
> big after all, I really have no idea.)

Ok, I'll just take this as the definite answer that full exception safety is probably possible somehow, but most probably a lot of
work to get all the details right.

We'll go with one of the work-arounds.

Thanks, Colin

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Lourival Vieira Neto
In reply to this post by Colin Hirsch
On Sun, Mar 15, 2015 at 10:50 AM, Colin Hirsch <[hidden email]> wrote:

>> On 13 March 2015 at 16:21 Roberto Ierusalimschy <[hidden email]> wrote:
>>
>> > That does look interesting, although we’d have to check whether it
>> > is possible for us to switch to LuaJIT. The last time I looked at it
>> > that was not possible for lack of 64bit integer support (unfortunately
>> > Lua’s default numeric type “double” is not at all appropriate
>> > to our applications, and our Lua 5.1 is configured to use int64_t
>> > instead, something that Lua is well designed to handle). However it
>> > seems that in the meantime LuaJIT has gained support for some boxed
>> > 64bit integers, which might be good enough if well integrated…
>>
>> (Out of topic) Can you give a brief explanation about why you need
>> 64bit integer support? (I am writing something about the introduction
>> of integers in Lua 5.3, and it would be good to have some more concrete
>> examples of why people need 64bit integers.)
>
> On a related note, we are currently considering upgrading from Lua 5.1 to Lua 5.2, rather than 5.3, because we _only_ need 64bit
> integers, and 5.2 can be configured to use them exclusively, just like the 5.1 we are currently using.
>
> We will of course first look into whether the floating point part of 5.3 can be safely and easily ignored in our use cases; our
> concern is that the implicit conversion form integer to float might strike at inconvenient times...

Perhaps you may want to take a look at this [1] patch, which removes
floating-point numbers completely from 5.3.

[1] https://github.com/lneto/lua/tree/no-float
--
Lourival Vieira Neto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Luiz Henrique de Figueiredo
> Perhaps you may want to take a look at this patch, which removes
> floating-point numbers completely from 5.3.

Can't it be done simply (or at least less intrusively) by defining Lua
numbers to be ints?

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Lourival Vieira Neto
On Mon, Mar 16, 2015 at 2:42 PM, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
>> Perhaps you may want to take a look at this patch, which removes
>> floating-point numbers completely from 5.3.
>
> Can't it be done simply (or at least less intrusively) by defining Lua
> numbers to be ints?

By simply redefining Lua numbers, I think not. Less intrusively,
definitely yes. I used this approach for three reasons: guarantee just
one execution flow for numbers, reduce the binary size and as a
exercise =).
--
Lourival Vieira Neto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 and C++ exceptions

Dirk Zoller-3
In reply to this post by Roberto Ierusalimschy

There are 64 bits identifiers out there which have to be preserved.
We currently still resort to hex-strings.

On 03/13/2015 04:21 PM, Roberto Ierusalimschy wrote:
That does look interesting, although we’d have to check whether it
is possible for us to switch to LuaJIT. The last time I looked at it
that was not possible for lack of 64bit integer support (unfortunately
Lua’s default numeric type “double” is not at all appropriate
to our applications, and our Lua 5.1 is configured to use int64_t
instead, something that Lua is well designed to handle). However it
seems that in the meantime LuaJIT has gained support for some boxed
64bit integers, which might be good enough if well integrated…
(Out of topic) Can you give a brief explanation about why you need
64bit integer support? (I am writing something about the introduction
of integers in Lua 5.3, and it would be good to have some more concrete
examples of why people need 64bit integers.)

-- Roberto