shyouhei / ruby-lang.org wrote:
> Nobuyoshi Nakada wrote:
> > It is not guaranteed that `ruby_xfree` can free a pointer allocated by other than `ruby_xmalloc` and so on.
> > You can't mix bare `malloc` and `ruby_xfree`.
> 
> Agreed.  I heard that DLLs can have their own malloc() implementation on Windows.  Even on POSIX variants, memory regions (e.g. mmap()-ed ones) are not always guaranteed to be free()-able.
> 
> This proposed C APIs are too easy to be misused when publicized.  And misuse of them directly results in SEGV.  I don't think it's a wise idea.

One place we can use this in C Ruby is ruby_getcwd() on GNU libc.

Yes, it's dangerous if misused.  Perhaps having a way to plug-in
and redefine alloc/free/realloc functions would be safe on a
per-T_STRING basis.

We can maybe use FL_USER{3,4,5}, and STR_NOFREE flags for
non-embed strings and allow up to 14 non-standard plug-in
*alloc implementations for users to define.

(4 bits; 16 implementations possible, 2 of which are built-in:
 1: normal malloc 2: no-free, replacing existing STR_NOFREE cases)

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>