Managed cstrings to avoid the need of Parrot_str_free_cstring

[NotFound]

This is another attempt to solve the problems of Parrot_str_free_cstring (need to ensure to call it in all code paths, lose the cstring some called function unexpectedly throws...).

It adds the new function Parrot_str_to_cstring_managed that returns some PMC (a ManagedStruct now, but this is an implementation detail) that contains the cstring, providing access to it via vtable get_pointer and frees it when destroyed.

[cotto]

I don't think this is a complete solution, though it'll certainly help in a large number of cases. The problem is that this can only work while the stack frame that holds a pointer to the UnmanagedStruct is active. In cases where we need to return a cstring to some other code, we'll get nice hard-to-reproduce errors when the GC fails to find a pointer to the container UnmanagedStruct PMC and collects it as garbage.

[NotFound]

Yes, the intended usage is for cases where the cstring is used as a local variable in a function (however, it also may be useful if the PMC is stored somewhere and used carefullly). Returning a c string to some other code is always difficult if we don't know for sure how it will be freed.

A way to help locate errors may be filling the cstring with 0xdeadbeef or something like that before freeing it, in non optimized builds.

[bacek]

Why don't introduce Parrot_str_to_const_cstring which will return raw pointer?

-- Bacek

[NotFound]

We already have Parrot_string_cstring (BTW needs a rename to current conventions), but usually we don't need a raw pointer to a parrot string content, but a C string.

[allison]

With the current state of the code, I can see why this is tempting. A better long-term solution is to a) stop using cstrings in our interfaces (with the exception of functions in the embedding API, and the possible exception of constant string arguments that are immediately converted to STRINGs), and b) add a reasonable coding standard restriction on the use of cstrings in Parrot code (something like "if it's used for more than 3 lines, it should be a STRING").

[jkeenan]

Can we get an update on the status of this ticket?

Thank you very much.

kid51

[NotFound]

The idea was no well received and the implementation is outdated by many parrot chnages, so rejecting ticket.