Hi Paul, On Thu, Feb 28, 2013 at 9:27 AM, Paul Moore <p.f.moore@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.