From: Eric Wong <normalperson@...>
Date: 2017-07-19T01:39:07+00:00
Subject: [ruby-core:82104] Re: register_fstring_tainted:FL_TEST_RAW(str, RSTRING_FSTR)

Koichi Sasada <ko1@atdot.net> wrote:
> http://ci.rvm.jp/
> 
> without "-DRGENGC_CHECK_MODE=2 -DVM_CHECK_MODE=2", many of tries are
> failing. How about to revert them and reconsider the implementation? (and my
> e-mail box will be helped, now I receive a hundred of failure
> notifications...)

OK, reverted in r59364

> Nobu and I are discussed about this implementation and it seems we can only
> use one table (an original fstring table). It will be simple and easy to
> find out bugs (hopefully).
> 
> (1) fix fstring_cmp()
> (2) introduce new fstring_hash()
> (3) introduce tainted string into fstring table
>   You want to share bare fstring body for tainted strings,
>   so that we find (or insert) bare fstring in advance and
>   insert made shared tainted fstrings.

OK, that sound possible good.

> Another question: "existing" technique helps from unlimited expanding of
> string table. But I'm not sure it will help the usual case of `Hash#[]=`
> because we already should have same string in fstring.

I made Hash#[]= only use existing strings because dstr caused
performance problems in bm_so_k_nucleotide [misc #9188]

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