[Gambas-user] Immutable strings and c functions returning allocated blocks, mmaped strings/objects

[Benoît Minisini]

Le 15/02/2020 à 08:51, Brian G a écrit :
> I am having an interesting time with functions that return allocated 
> blocks that represent zero terminated strings
> 
> such as gnu readline(prompt as string) as string. This function provided 
> and editable line on the terminal, it returns the input as a string 
> buffer allocated from the heap. I do this from some c functions as well, 
> but into the shared memory buffers used by task to transfer information. 
> The Returned pointer is freed after use, but bad pointers are left.
> 
> It appears that You have implemented string as an immutable value, even 
> mid simply return a pointer in the original string and manages a length 
> internally without changing the string or making any copy, which is fast.
> 
> no matter what you do, the string is immutable, so a = b, just creates a 
> copy of a pointer to the original string, its immutable right.
> so adding it to a collection, or string array, or anything else leaves a 
> bad pointer when its freed later. Strange and unpredictable results. How 
> does the garbage collector handle the pointers if the value is not freed 
> and the variable goes out of scope. It appears to sometimes cause a 
> crash, could just be my bad code.
> 
> The same issue arises with shared memory segment, that contains string 
> information. Instead this time the pointers are all into the area not 
> managed by the Gambas gc. When the variables assigned for example with s 
> = string@(pSharedMem) <mailto:string@(pSharedMem)> goes out of scope 
> what happens? Does that change if a global points to the same string in 
> shared memory as well?... umm Boom segfault, if the unmap is done before 
> the variable goes out of scope.
> 
> How is it handled, should I be making copies of strings, is there a way 
> to tell the gc not to collect pointers for certain variables when they 
> go out of scope.
> This is a little complex, but I am running into some of these issues, 
> there seems to be only one way of getting a copy right now, that's x = 
> string(1,string@(pointer)) maybe there is a faster way. Is the gc smart 
> enough to know that a pointer is used in a higher level scope.
> 
> Does the new index on a string take into account the immutable nature ? 
> eg, a = "asdasdadsad": b = mid(a,2,4) : a[3] = 34 or does it
> create a new copy on changing a value?
> 
> If you can help me understand this so I can find a fast work around or 
> solution..
> 
> Thank You
> Brian G
> 

The Gambas strings belong to the interpreter. So don't send a pointer on 
a Gambas string to a C function, unless the argument is 'const char *'.

String@() returns a lazy copy of the pointed string (i.e. a constant 
string that is transformed into an immutable copy of the string when 
needed). It requires that the pointer does not disappear of course 
behind the scene, so you have to use a trick to ensure a copy is done 
immediately (like the one you did for example).

This is one of the reason why I try to never use shared memory, and use 
serialization through a pipe instead. The other one being 
synchronization problems.

Regards,

-- 
Benoît Minisini