Re: ffi idea: strip null pointers
- From: Cosmin Apreutesei <cosmin.apreutesei@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Mon, 4 Jun 2012 23:08:36 +0300
On Mon, Jun 4, 2012 at 7:46 PM, Mike Pall <mike-1206@xxxxxxxxxx> wrote:
> Cosmin Apreutesei wrote:
>> Isn't there a speed loss on any of the many automatic conversions that
>> the ffi does between C and Lua types?
>
> Not really.
>
> [A special case is 'bool'. But then you probably want to branch on
> that, or you wouldn't use a bool. There's special logic to avoid
> the overhead, if you don't use the result.]
>
>> Why is this particular one
>> unacceptable while all the others are acceptable? Just curious.
>
> It needs a test and branch that cannot be optimized away. That is,
> even if NULL pointers cannot happen or none of the following code
> needs or wants that logic.
>
> [Implicitly nullable types are considered a big no-no in some
> circles. The languages that have gone down that path (e.g. Java)
> are riddled with tons of automatic NULL pointer checks. It's a
> tough job to eliminate them and it's not always successful. There
> are many research papers on that topic.]
>
>> But what's the worst that can happen in practice from
>> losing the type of a null pointer?
>
> Pointer assignment compatibility would break. nil is always
> compatible, because it's treated the same as "(void *)0". But in
> general a "foo *" result cannot be assigned to a "bar *" field.
> The same code might seem to work, if you always happen to return a
> NULL pointer. But it would break, once you don't. Ugh.
I think this argument is invalid in a subtle way that needs explaining
(not that I think it would make any difference, speed always wins over
semantics, but just for clarification).
In static languages people have to reserve a segment from the range of
a scalar type for special values like "error" or "unknown". So they
use -1 to signal an error case and the address 0 (aka NULL) to specify
lack of a value. In C, NULL is just a convention. From the pov. of the
language, the zero address is as valid as any other, hence you can't
pass a NULL bar* for a foo*. But everybody on earth reserves the
address 0 for the special meaning missing/empty/not-valid/unknown/etc.
which is _the same meaning_ for foo* as it is for bar* hence it is
_logically transferable_ from foo* to bar*, but C doesn't let you do
that because it doesn't know anything about NULL since that's just a
convention, necessary in any static-typed language.
In Lua we no longer have to revert to tricks like NULL. We don't think
having a "nil string" incompatible with a "nil number" as a neat idea
either. The ffi is a Lua API not a C API and deals with C APIs not
with the C language, it doesn't have to copy C's world-view if it's
not useful. This "guarding" against assigning a NULL foo* to a bar* is
not a useful property in Lua (I think it's not useful in C either, you
just can't have it otherwise in a static language).
>
>> What would break?
>
> Finn just gave you an example.
>
>> Sorry if I sound incisive but in my particular
>> experience with winapi, since I got rid of NULLs it made my life
>> easier and couldn't find one reason to want them back, so I was
>> curious to know what am I missing.
>
> C has NULL pointers. The FFI is a low-level API that deals with C.
>
> --Mike
>
Other related posts:
