[Python-Dev] cffi in stdlib
arigo at tunes.org
Thu Feb 28 10:06:00 CET 2013
On Thu, Feb 28, 2013 at 9:27 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> Presumably ffi.NULL isn't needed and I can use 0? (After all, 0 and NULL are equivalent in C, so that's
> not a correctness issue).
Indeed. I created
In C, NULL is typically "#define NULL (void *)0", not just 0, which
means that there are not 100% equivalent. But it's true that in C you
can pass the constant 0 to mean "a NULL pointer argument". The fact
that it's not working this way in CFFI is definitely a bug.
>> That's a slightly unfair example, because in this case it happens to
>> work with ctypes without specifying the argtypes and the restype. I
>> would argue that this feature of ctypes is not a good thing: it's
>> mostly the same as saying "you only need to declare argtypes and
>> restype if you get nonsense results or segfaults".
> That's a bit unfair. I'd say "you only need to declare argtypes if
> you're dealing with things more complex than integers, strings and
> null pointers". Which means you're fine for a huge proportion of the
> Windows API.
Yes, you're right, and the 32-bit Windows platform is still important.
However, it only works on 32-bit. On typical 64-bit Posix
environments, if you don't declare argtypes/restype, you usually end
up very quickly with confusion between "int" and "long". And I think
that even on 64-bit Windows, passing 0 as a NULL pointer is buggy,
because it will pass a 32-bit 0. (It may be that it doesn't actually
make a difference and works anyway, but I'm not sure.) Similarly, a
function that returns a pointer (e.g. a handle on Windows) will not
work without an explicit restype on any 64-bit platform I know of.
"Explicit is better than implicit"...
More information about the Python-Dev