Ticket #1083 (closed patch: wontfix)

Opened 12 years ago

Last modified 11 years ago

Managed cstrings to avoid the need of Parrot_str_free_cstring

Reported by: NotFound Owned by:
Priority: normal Milestone:
Component: core Version: 1.6.0
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


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.


managed_cstring.patch Download (13.0 KB) - added by NotFound 12 years ago.

Change History

Changed 12 years ago by NotFound

Changed 12 years ago by 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.

Changed 12 years ago by 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.

Changed 12 years ago by bacek

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

-- Bacek

Changed 12 years ago by 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.

Changed 12 years ago by 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").

Changed 11 years ago by jkeenan

  • component changed from none to core

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

Thank you very much.


Changed 11 years ago by NotFound

  • status changed from new to closed
  • resolution set to wontfix

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

Note: See TracTickets for help on using tickets.