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")
> (setf s (pack _struct_string 0 0))
> (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
. 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.