[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaJIT FFI: Semantics of undefined numeric conversions (e.g. huge double to int)
- From: Mike Pall <mikelu-1109@...>
- Date: Mon, 19 Sep 2011 00:39:34 +0200
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