`#\Null` mysteriously disappears from strings

[dragoncoder047]

uLisp:

> (length (string #\Null))
0
> (char (apply #'concatenate (cons 'string (mapcar #'string '(#\Null #\A)))) 0)
#\A

Expected (as GNU Clisp):

CL-USER> (length (string #\Null))
1
CL-USER> (char (apply #'concatenate (cons 'string (mapcar #'string '(#\Null #\A)))) 0)
#\Null

[technoblogy]

It's not mysterious! Null is used as a string terminator in uLisp.

[dragoncoder047]

Well, I can't say I didn't expect that. 😀

I was thinking about the possible use-cases of strings with nulls in them, and binary-oriented serial communication channels came to mind. A user might have a device that expects ASCII data, but instead of being separated by spaces or newlines it is separated by nulls. If it includes a long string of static configuration options, it might work to just put it all in a string and send the string.

[technoblogy]

The uLisp string format could be changed to fix this, but I'm not sure how useful/necessary that would be.

[dragoncoder047]

One idea I did have but never got around to implementing would be that on the "last chunk" of the string that may not have all the bytes filled and will be where the next character is put in when the string is being built, the car pointer can instead of pointing to NULL can hold a number for the number of remaining character spaces in the cdr part.

For example, if there are 4 characters held in the last chunk the car would indeed be 0, if there were 3 characters used the car would be 1, etc. And if it is not the last chunk, the car would naturally point to memory in the Workspace and the car would be greater than sizeof(int).

Then buildstring() could look at and modify the car pointer to keep track of the number of characters used, instead of checking to see which bytes are empty, which goes awry when one of the bytes is actually supposed to be zero (i.e. #\Null)

I don't know how this will affect the garbage collector, and I don't want to break stuff so I haven't tried to implement this idea yet.