[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4762: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4764: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4765: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4766: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3897)
newlispfanclub.alh.net • View topic - How to unpack NULL string in libffi

How to unpack NULL string in libffi

Q&A's, tips, howto's

How to unpack NULL string in libffi

Postby kosh » Mon May 18, 2015 6:28 pm

kosh
 
Posts: 69
Joined: Sun Sep 13, 2009 5:38 am
Location: Japan

Re: How to unpack NULL string in libffi

Postby Lutz » Mon May 18, 2015 8:11 pm

Lutz
 
Posts: 5279
Joined: Thu Sep 26, 2002 4:45 pm
Location: Pasadena, California

Re: How to unpack NULL string in libffi

Postby TedWalther » Tue May 19, 2015 1:46 am

Lutz, I'm not suggesting to return nil for NULL pointer. I appreciate you want to keep C data types separate from the LISP ones. But when dealing with char*, you are treating it as a string; surely it isn't an error for a function to return either a string, or a nil for "no string"? I suggest this, because char* isn't returning a pointer, you disabled that in 10.4.3, it is returning a string. I'm comfortable with a function returning either a valid string or a nil. Otherwise, the void* like you suggest is the right way. I asked for "nil" not to match it up with NULL, but because the char* implies more integration with LISP, doing things in a LISPy way, so I can forget about the C a bit.

Returning an error in this case is very surprising; when we use char* and we usually get a string, then for NULL we would expect "no string". Not the empty string, but just a "false" value.

Also if people pass "nil" to a C function that has char*, the NULL translation makes sense, because it means "no string, no pointer, nothing". It maintains the integration between newLisp and C. If they pass nil when it is void*, that should be an error. I only say this, because you made it clear in the documentation that char* doesn't map to actual address, it is glue that translates between strings and C types.

So, I saw char* as a convenience thing, when we only need void*. And it is a nice convenience, I love how easy it is to make a C function integrate with newLisp like they are soul-mates.

I would suggest also that if a "char*" is one of the functions arguments, that ONLY a string or nil would be allowed, and not a number/address. To maintain the distinction that char* is an integration convenience.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
TedWalther
 
Posts: 605
Joined: Mon Feb 05, 2007 1:04 am
Location: Abbotsford, BC


Return to newLISP in the real world

Who is online

Users browsing this forum: No registered users and 1 guest