[Python-Dev] cffi in stdlib

[Armin Rigo]

Hi Paul,

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
https://bitbucket.org/cffi/cffi/issue/61/convert-0-to-a-null-pointer.
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"...


A bientôt,

Armin.