Re: ffi.string(nil) seg faults
- From: Francesco Abbate <francesco.bbt@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 7 Jan 2013 22:20:38 +0100
2013/1/6 Cosmin Apreutesei <cosmin.apreutesei@xxxxxxxxx>:
>> For me a NULL pointer should not be considered equal to nil
>
> Why? I'm asking because in my bindings I convert NULL results to nil
> (see discussion[1]). What's the downside of that?
Probably it is ok to return nil instead of NULL in bindings. The
problem is with NULL pointer in LuaJIT. The reason is that in Lua a
nil evaluates to "false" in a boolean context. With the FFI interface
a NULL pointer is considered equal to nil but does evaluate to "true"
in a boolean context. This violates the following identity that is
generally true in Lua:
IF a == b THEN (not a == not b)
I think this a little bit unfortunate since Lua was designed in a very
coherent manner for this pint of view and a few of the extensions
introduced with FFI brings some incoherences. This is even more crying
with the semantic changes introduced by Mike with enums. These can be
considered equal to both a string literals and a number so that you
violate also the following identity:
IF a == b and b == C THEN a == c
For example you can have:
'MY_ENUM_VALUE' == a and a == 3
but NOT "MY_ENUM_VALUE" == 3.
This is a similar problem of the Javascript equality operator '=='
even if, to be honest, the case of Javascript the problem is much
worst. The problem in Javascript is that it is incoherent with
fundamental types like numbers or strings. This turns out to be a
disaster and many authors like Douglas Crockford recommend to always
use the "===" operator.
In LuaJIT this is a minor problem because it does just concerns cdata
types and the programmers can easily avoid the problem by explicitly
checking.
Francesco
Other related posts:
