lua-users home
lua-l archive

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



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