On Wed, Oct 6, 2010 at 8:14 PM, Matthew Mondor <mm_li...@pulsar-zone.net> wrote: > On Wed, 6 Oct 2010 16:12:28 -0500 > Javier Guerra Giraldez <jav...@guerrag.com> wrote: > >> just curious, why was that needed? is floating point forbidden by >> code conventions? > > The non-software floating point support is only available in userland > if I remember. However I also have a question: is switching to long > long including the switch to a fixed point implementation, or is it > an integer-only Lua implementation for kernel use?
The number format was simply redefined to an integer type. We have no built-in fixed point implementation, but you can provide floating point as an external library or use your own fixed point representation in your scripts. > As for possible problems like stack usage, I guess that if it's running > under an LWP context it probably is less restricted, but I agree that > preventing interpretation of non-trusted scripts would be better than > trying to cripple the Lua runtime as much as possible. Considering > that the cryptographic code export is now less restrictive than it used > to be, possibly that signature checking would also be nice to have, > other than only limiting access to the superuser. I do not see real problems in stack usage. I think the most important concern is about liveness, but I would like to warn that liveness and trust problems is also present in traditional loadable kernel modules. > In fact, that would be nice for new-style kernel modules, too, > especially if part of future plans for supporting them include > eventually providing binary-only upgrades of some components). > A build-time inclusion of the wanted public keys to trust third party > components from would not be hard to implement... > > Thanks, > -- > Matt > Cheers, -- Lourival Vieira Neto