+* Generally follow LuaJIT's ffi: http://luajit.org/ext_ffi.html
+* Be explicit: almost no automatic conversions. Here is the set
+ of automatic conversions: the various C integer types are
+ automatically wrapped and unwrapped to regular applevel integers. The
+ type ``char`` might correspond to single-character strings instead;
+ for integer correspondance you would use ``signed char`` or ``unsigned
+ char``. We might also decide that ``const char *`` automatically maps
+ to strings; for cases where you don't want that, use ``char *``.
+* Integers are not automatically converted when passed as vararg
+ arguments. You have to use explicitly ``ffi.new("int", 42)`` or
+ ``ffi.new("long", 42)`` to resolve the ambiguity. Floats would be
+ fine (varargs in C can only accept ``double``, not ``float``), but
+ there is again ambiguity between characters and strings. Even with
+ floats the result is a bit strange because passing a float works
+ but passing an integer not. I would fix this once and for all by
+ saying that varargs must *always* be a cdata (from ``ffi.new()``).
+ The possibly acceptable exception would be None (for ``NULL``).
+* The internal class ``blob`` is used for raw-malloced data. You only
+ get a class that has internally a ``blob`` instance (or maybe is a
+ subclass of ``blob``) by calling ``ffi.new(struct-or-array-type)``.
+ The other cases, namely the cases where the type is a pointer or a
+ primitive, don't need a blob because it's not possible to take their
+* It would be possible to add a debug mode: when we cast "struct foo"
+ to "struct foo *" or store it in some other struct, then we would
+ additionally record a weakref to the original "struct foo" blob.
+ If later we try to access the "struct foo *" but the weakref shows
+ that the blob was freed, we complain. This is a difference with
+ ctypes, which in these cases would store a strong reference and
+ keep the blob alive. "Explicit is better than implicit", so we ask
+ the user to keep a reference to the original blob alive as long as
+ it may be used (instead of doing the right things in 90% of the cases
+ but still crashing in the remaining 10%).
+* LuaJIT uses "struct foo &" for a number of things, like for ``p``
+ if ``p`` is a "struct foo *". I suppose it's not a bad idea at least
+ to have internally such types, even if you can't specify them through
+ pycparser. Basically "struct foo &" is a type that doesn't own a
+ blob, whereas "struct foo" is the type that does.
+* LuaJIT uses "int[?]" which pycparser doesn't accept. I propose
+ instead to use "int" for the same purpose (its use is anyway quite
+ close to the C standard's use of "int").