lua-users home
lua-l archive

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


Philipp Kutin wrote:
> From reading the documentation, it looks like LuaJIT's FFI is the
> perfect tool for making engine and game functions/structures
> accessible from the scripting language, where of course only "safe"
> functions should be made visible directly (for example, those taking
> only scalar numbers).

Umm, why? If the scripts originate from the same trust domain,
there's no point in adding any restrictions. You can blow up
memory or cause a hang (not caught by hooks) just with the
standard Lua library. And if the scripts are untrusted, better
watch out -- a truly perfect sandbox for Lua is hard.

> But as far as I can see, the FFI docs don't specify what happens
> for numeric conversions that are undefined per C standard, such
> as downcasting a number greater than INT_MAX to an int.

It relies on C and/or machine code to do the conversion, so it has
the same amount of 'undefinedness'.

Actually, I can guarantee that it doesn't cause an exception. But
the result for undefined inputs is definitely platform-dependent.
It could be anything, e.g. 0, INT_MIN, INT_MAX or a random result,
depending on the input.

> So, in every "interesting" case, the out-of-range double is
> apparently converted to INT_MIN, but can I rely on this or is this a
> coincidental side-effect of the implementation?

No, you cannot rely on this. It just so happens to be the standard
behavior on x86 and x64. But I might add optimizations to the JIT
compiler that explicitly rely on the inputs being defined, which
may cause other results for out-of-range inputs.

> For example, the double to int conversion is listed as
> 
>     double -->^trunc int,
> 
> but what is "truncation" supposed to mean in this particular
> context?

Truncation means rounding towards zero: 1.5 -> 1, -1.5 -> -1

This doesn't say anything about out-of-range inputs. But at the
top of the semantics page it says that it follows the C standard
wherever possible, so out-of-range inputs are undefined.

--Mike