[Ecls-list] C-STRINGs and lisp strings

[Juan Jose Garcia Ripoll]

Maciek Pasternacki wrote:

>It seems there is (should be) *always* room for a terminating null, and said
>null, at x->string.self[x->string.dim], if not earlier; so if null is not set,
>something seems to be wrong at some point, but it should be possible just
>to set it without segfaulting.
>
The point is not that. ECL always stores L+1 characters in a string, 
where L is the expected size and the last character is enforced to be zero.

The problem is that there are strings in lisp which seem to have less 
characters because they have fill pointers. Take, for instance this example

 > (progn
    (setf *a* (make-array 4 :element-type 'character :fill-pointer 0 
:initial-element #\Space))
    (vector-push #\h *a*)
    (vector-push #\i *a*)
    (vector-push #\! *a*)
    *a*)
"hi!"

Well, the output string seems to have three characters but it has 4! So 
when you pass it to the C world, it sees "hi! " and not "hi!" because 
the terminating zero is after the fourth character, not after the #\! as 
some people would expect. This problem is not so artificial: it may 
happen when you call FORMAT to produce a string, when you concatenate 
sequences, etc. I do not remember many functions which are forced to 
output simple-string.

My question is not so much as to whether we should protect users or not. 
I just want to come up with a solution which is compatible with UFFI and 
with people's expectations. If the solution is to set the zero after the 
'!' then ok, I can fix the function that takes pointers out of strings 
to produce copies when required.

[...After some thinking...]

I think I have found the right fix. Reading the UFFI manual, C-STRING is 
expected to be some type of string that can be passed to the C world. If 
one expects to have some "buffer" which can be written to by a C 
routine, then one has to create a C-STRING. Ok then the solution is to 
enforce that these C-STRING be a lisp simple-string . In other words, a 
string which has no fill pointer and has as many characters as the user 
expected. Then ECL's rule that all strings have a null character at the 
end will be enough.

The fix has been committed to CVS. Please raise your hands if I am 
allowed to close the associated bug report in Sourceforge.

Regards,

Juanjo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jlr.vcf
Type: text/x-vcard
Size: 389 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20050628/37c4388b/attachment.vcf>