[Ecls-list] Re: Latest changes

[Maciek Pasternacki]

Juan Jose Garcia Ripoll <jlr at ...> writes:

> Just to remaind what the problem is, you pass strings with fill pointers 
> to the C world. It is the extra junk after the fill pointer which causes 
> your problem, because the C code will see this junk. The FFI interface 
> hence cannot simply get a pointer to the data in the string, but should 
> create a new copy. However both cases have problems: if we do not make a 
> copy, the C code gets junk, if we make a copy, the string that is passed 
> to the C world is not the same one and we cannot use this string to get 
> data from the C world.

#v+ ecldev.info
3.6 Strings
===========

A string, both in Common-Lisp and in ECL is nothing but a vector of
characters. Therefore, almost everything mentioned in the section of
arrays remains valid here. The only important difference is that ECL
stores strings as a lisp object with a pointer to a zero terminated C
string. Thus, if a string has N characters, ECL will reserve N+1 bytes
for the string. This allows us to pass the string `self' pointer to any
C routine.

   If X is a lisp object of type string, we can access the following
fields:
`x->string.dim'
     Maximum number of characters that it can contain.

`x->string.fillp'
     Actual number of characters in the string.

`x->string.self'
     Pointer to the characters.
#v-

#v+ src/c/string.d
cl_object
cl_alloc_simple_string(cl_index l)
{
	cl_object x;

	x = cl_alloc_object(t_string);
	x->string.hasfillp = FALSE;
	x->string.adjustable = FALSE;
	x->string.displaced = Cnil;
	x->string.dim = (x->string.fillp = l);
	x->string.self = (char *)cl_alloc_atomic(l+1);
	x->string.self[l] = x->string.self[0] = 0;
	return(x);
}
#v-

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.