lua_newthread etc.

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

lua_newthread etc.

Albert-Jan Brouwer-2
Some remarks regarding Lua 5.0 beta:

lua_newthread() does not seem to be checking its
state allocation (luaE_newthread->mallocstate
in state.c) for possible failure.

Also, has it been considered to extend the math
library with isnan() and infinity() so that
Lua can check against exceptional floating point
values?

---
Albert-Jan

Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Roberto Ierusalimschy
> lua_newthread() does not seem to be checking its
> state allocation (luaE_newthread->mallocstate
> in state.c) for possible failure.

It doesn't need to. luaM_malloc never returns NULL when called with a
non-null lua state (it throws an error, instead).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Luiz Henrique de Figueiredo
In reply to this post by Albert-Jan Brouwer-2
>lua_newthread() does not seem to be checking its state allocation
>(luaE_newthread->mallocstate in state.c) for possible failure.

Thanks, we'll check this.

>Also, has it been considered to extend the math library with isnan() and
>infinity() so that Lua can check against exceptional floating point values?

No, because these functions are not ANSI C functions. At least, not C89.
Perhaps C99 contains them, I'm not sure, but our target language for
implementing Lua will remain C89 until C99 compilers become the norm. Even
for C89, which has been a standard for 10 years now, compilers have their
own ideas about dark and not so dark corners of the languague, which we
have learned to avoid... I expect that the same thing will happen with C99
compilers, and C99 seems to have quite a large share of dark corners. :-(

On the other hand, I do have a draft IEEE math library that I'll probably
distribute when Lua 5.0 final is released. It's pretty simple anyway.

Finally, you can write those in Lua:

 function isnan(x) return x~=x end
 function isinfinity(x) return x+1==x end

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Gunnar Zötl
In reply to this post by Albert-Jan Brouwer-2
Hi,

AJB> Also, has it been considered to extend the math
AJB> library with isnan() and infinity() so that
AJB> Lua can check against exceptional floating point
AJB> values?

actually, you can. Well, on some platforms, at least... not sure about
that. I'm pretty sure it depends on the floating point implementation
your C compiler uses. IEEE should be OK. You can write something like

> infinity=1/0
> =infinity
1.#INF
> NaN=infinity/infinity
> =NaN
-1.#IND

(I assume the outcome of infinity/infinity to be not a number.)

You can then compare and even calculate with these:

> =1/infinity
0
> =infinity/1
1.#INF
> =infinity == (87123456/0)
true
> =infinity == 17
false
> =NaN+1
-1.#IND

seems to look like what one would expect. Of course, technically the
third querys result is not correct, but it is the behaviour one would
like to have, I think.

Gunnar


Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Juergen Fuhrmann
In reply to this post by Luiz Henrique de Figueiredo
Hello,

Sorry, but I need to correct one point here...

>  Wed, 22 Jan 2003 15:16:27 -0200
>  Luiz Henrique de Figueiredo <[hidden email]> wrote:
>
[...]
>  
>  On the other hand, I do have a draft IEEE math library that I'll probably
>  distribute when Lua 5.0 final is released. It's pretty simple anyway.
>  
>  Finally, you can write those in Lua:
>  
>   function isnan(x) return x~=x end
>   function isinfinity(x) return x+1==x end

which mathematically  would be right, but numerically  would be wrong.
By  this, you  would get  something like  the inverse  of  the machine
epsilon which is defined as the smallest number for which

1+eps > 1 

in  the  floating  point  arithmetic.   In ANSI  C,  this  is  exactly
DBL_EPSILON  resp.   FLT_EPSILON,  which  for  IEEE  have  the  values
2.2204460492503131e-16 resp. 1.19209290e-07.


If the  IEEE rules (which I don't  know well) 1.79769313486231570e+308
would state that

infinity>x 

for all floating point numbers, we could use something like

function isinfinity(x) return x>DBL_MAX end

where  DBL_MAX takes  the value  1.79769313486231570e+308  in float.h.
But please  don't enter  this value  from within Lua,  as there  is at
least  some danger  that sscanf  will mess  up the  value.  Rather, it
should be entered  using lua_pushvalue from within C  to get the exact
valu.


Perhaps it  was a wise  decision by the  ANSI commitee not  to include
this stuff into ANSI C because on many systems, this functionality can
be    toggled     via    assembler    statements     or    environment
variables.  E.g.  many  numerical  anlaysts rather  like  to  generate
exceptions on 1/0 than checking  for infinity or nan, and switch these
feature off.  On VAXen, you have floating numbers not covered by IEEE.

Juergen Fuhrmann






Reply | Threaded
Open this post in threaded view
|

RE: lua_newthread etc.

Albert-Jan Brouwer-2
In reply to this post by Albert-Jan Brouwer-2
> > lua_newthread() does not seem to be checking its
> > state allocation (luaE_newthread->mallocstate
> > in state.c) for possible failure.
> 
> It doesn't need to. luaM_malloc never returns NULL
> when called with a non-null lua state (it throws
> an error, instead).

This may be fine when creating a co-routine from
a Lua context. But I am calling lua_newthread from
a C context. Does that mean I should call lua_newthread
through lua_pcall if I am to prevent my application
from exiting on an error? If so, what other Lua API
functions should be treated with similar caution?

---
Albert-Jan

Reply | Threaded
Open this post in threaded view
|

RE: lua_newthread etc.

Luiz Henrique de Figueiredo
In reply to this post by Albert-Jan Brouwer-2
>This may be fine when creating a co-routine from
>a Lua context. But I am calling lua_newthread from
>a C context. Does that mean I should call lua_newthread
>through lua_pcall if I am to prevent my application
>from exiting on an error? If so, what other Lua API
>functions should be treated with similar caution?

In C anything can happen. Any errors that occur "outside" the Lua virtual
machine cannot be reported to the host program. Until Lua 4.0 (inclusive),
Lua called "exit" when facing such errors. Lua 5.0 allows you to register your
own panic function (but you cannot return to Lua after this; Lua will exit if
you do). Lua 5.0 also introduced lua_cpcall to run C functions in protected
mode. One use of this is exactly to run C code and still catch any errors
gracefully. The interpreter lua.c uses this mechanism.

Bottom line: start your Lua transactions in the host program with a C function
that is called via lua_cpcall and don't worry about errors (except that you
have to catch them only once, after the call to lua_cpcall). See lua.c in
Lua 5.0 (beta).
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Roberto Ierusalimschy
In reply to this post by Albert-Jan Brouwer-2
> Does that mean I should call lua_newthread through lua_pcall if I am to
> prevent my application from exiting on an error? If so, what other Lua
> API functions should be treated with similar caution?

If you are worried about memory-allocation failures, then most
API functions need that caution. Most functions in Lua may need to
allocate memory, and if this fails Lua throws an error. So, yes, to
prevent your application to exit you should call them in protected mode.
You can do this with lua_pcall, or with the new (not in the manual, yet)
lua_cpcall:

LUA_API int lua_cpcall (lua_State *L, lua_CFunction func, void *ud);

You pass the function to be called in protected mode and a generic
userdata for it (it will be available as a userdata argument to the
function). See an example of use in lua.c.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

unsubscribe

Pascal Maillard
In reply to this post by Juergen Fuhrmann


Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Jay Carlson
In reply to this post by Luiz Henrique de Figueiredo
> Finally, you can write those in Lua:
>
>  function isnan(x) return x~=x end
>  function isinfinity(x) return x+1==x end

Your isinfinity() won't work once you run out of mantissa bits (at around
1e16 in IEEE doubles), where 1e16+1=1e16.

Jay


Reply | Threaded
Open this post in threaded view
|

Re: lua_newthread etc.

Luiz Henrique de Figueiredo
In reply to this post by Albert-Jan Brouwer-2
>>  function isinfinity(x) return x+1==x end
>
>Your isinfinity() won't work once you run out of mantissa bits (at around
>1e16 in IEEE doubles), where 1e16+1=1e16.

Ok, right. Sorry about that. On IEEE machines, you can use

  function isinfinity(x)
   if x>0 then return x==(1/0) else return x==(-1/0) end
  end

--lhf