On Tue, Jun 30, 2009 at 3:13 PM, Tobias Rautenkranztobias@rautenkranz.ch wrote:
I had something like in man malloc in mind: "If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()."
How about making CFFI:FOREIGN-ALLOC always return a null pointer regardless of what malloc() would do? Would that work?
I need this for: QByteArray ( const char * data, int size ) I guess the malloc definition should also be fine for stuff like: ssize_t write(int fd, const void *buf, size_t count);
Requiring a null pointer might be to restrictive; SBCL e.g.: (cffi:foreign-string-alloc "" :null-terminated-p nil) #.(SB-SYS:INT-SAP #X080961A8) 0
How about making CFFI:FOREIGN-ALLOC always return a null pointer regardless of what malloc() would do? Would that work?
Yes; this is fine with me. I was just thinking one could prevent testing for :count 0 by allowing the same return value as malloc() and thus not introduce an overhead.