Re: LuaJIT FFI: Semantics of undefined numeric conversions (e.g. huge double to int)

[Philipp Kutin <p@...>]

On 09/19/2011 12:39 AM, Mike Pall wrote:
> 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.
The scripts are coded by gamers who wish to extend the functionality of 
the game, so it's not at the same trust level as the engine/game C code. 
The sandbox isn't so much supposed to be hardened against malicious 
attacks, but operations visible to the script coder should definitely be 
consistent across platforms and versions.

> 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.
OK, that's good to know, even though it means that pretty much all 
functions will have to be wrapped.

> 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.
Yeah, I figured that after my post, but still, the documentation doesn't 
explicitly mention that carrying out C-undefined conversions gives 
undefined results. In fact, it suggests otherwise if you search for 
"undefined":

[quote]
Indexing a pointer/array: (...) An error is raised if the element size 
is undefined or a write access to a constant element is attempted.

Pointer arithmetic: (...) An error is raised if the element size is 
undefined.

64 bit integer arithmetic: (...) The undefined cases for the division, 
modulo and power operators return 2LL ^ 63 or 2ULL ^ 63.
[/quote]

Especially the last might suggest to a reader that all invalid 
conversions are somehow trapped and produce a special constant, and 
phrasings like "These conversion rules are *more or less* the same as 
the standard C conversion rules" add to the uncertainty.

So, can something like the following be added to the spec?:

"
... it closely follows the C language semantics, wherever possible. 
Specifically, <this and that> should be considered undefined behaviour 
as per C standard.
"

It would give a lot more comfort to have this explicitly spelled out to 
bone-headed people like me :)


--Philipp