In version 10.6.3 this will cause and error message to be thrown:
Code: Select all
newLISP v.10.6.3 64-bit on OSX IPv4/6 UTF-8 libffi, options: newlisp -h
> (struct '_struct_string "char*" "long")
_struct_string
> (setf s (pack _struct_string 0 0))
"\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"
> (unpack _struct_string s)
ERR: cannot convert NULL to string in function unpack
>
... the same happens when a libffi imported function returns NULL or when calling
get-string with
0. To avoid this you could either use:
Code: Select all
(catch (unpack _struct_string s) 'ret)
this will return
nil and an error message in
ret, or will return
true and the returned list in
ret.
Another possibility is using
void* as a type instead and test if a
0 comes back, before doing a
get-string on a valid pointer.
get-string on a NULL ptr will throw the same error message.
Like you, Ted too suggested returning a
nil for a NULL pointer. I am afraid people then start passing
nil as parameter (instead of 0) when calling functions. The implications in newLISP code base are just too much when treating NULL as nil and vice<->versa. The current solution just inserts a NULL test in the internal string => lisp cell - stuffString() - C function and this way covers all occurrences in the system when trying to convert a
0 (NULL) to a a string, and there are many occurrences.
In most cases a NULL ptr will occur, this is an exception, not necessarily an error but a situation relatively rare.
Another solution would be, to not throw an error but return a
"(null)". I think some GNU C-library functions to this. This could be implemented, instead of throwing the error as done currently in 10.6.3.
But I still prefer the error message and trapping it with
catch, because in any case when ther is a chance for NULL then one would have test for
"(null)" in the returned string of a function or
unpack. As this is an execpetional case working with
catch seems to be more natural.