[#79914] [Ruby trunk Bug#13282] opt_str_freeze does not always dedupe — normalperson@...
Issue #13282 has been reported by Eric Wong.
4 messages
2017/03/05
[#80140] [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus) — shyouhei@...
Issue #13295 has been updated by shyouhei (Shyouhei Urabe).
5 messages
2017/03/13
[#80362] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— Eric Wong <normalperson@...>
2017/03/26
shyouhei@ruby-lang.org wrote:
[#80368] Re: [Ruby trunk Feature#13295] [PATCH] compile.c: apply opt_str_freeze to String#-@ (uminus)
— SASADA Koichi <ko1@...>
2017/03/27
On 2017/03/26 15:16, Eric Wong wrote:
[#80205] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint — Eric Wong <normalperson@...>
duerst@ruby-lang.org wrote:
4 messages
2017/03/17
[#80213] Re: [ruby-cvs:65166] duerst:r58000 (trunk): clarifiy 'codepoint' in documentation of String#each_codepoint
— Martin J. Dürst <duerst@...>
2017/03/17
Hello Eric,
[#80290] [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch — normalperson@...
Issue #13355 has been reported by normalperson (Eric Wong).
4 messages
2017/03/23
[#80410] Re: [Ruby trunk Feature#13355] [PATCH] compile.c: optimize literal String range in case/when dispatch
— Eric Wong <normalperson@...>
2017/03/27
normalperson@yhbt.net wrote:
[#80415] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
5 messages
2017/03/28
[#80488] [Ruby trunk Feature#12589] VM performance improvement proposal — vmakarov@...
Issue #12589 has been updated by vmakarov (Vladimir Makarov).
4 messages
2017/03/29
[ruby-core:79838] Re: [Ruby trunk Feature#13252] C API for creating strings without copying
From:
Eric Wong <normalperson@...>
Date:
2017-03-01 08:06:23 UTC
List:
ruby-core #79838
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>