[#28687] [Bug #2973] rb_bug - Segmentation fault - error.c:213 — rudolf gavlas <redmine@...>

Bug #2973: rb_bug - Segmentation fault - error.c:213

10 messages 2010/03/16

[#28735] [Bug #2982] Ruby tries to link with both openssl and readline — Lucas Nussbaum <redmine@...>

Bug #2982: Ruby tries to link with both openssl and readline

16 messages 2010/03/18

[#28736] [Bug #2983] Ruby (GPLv2 only) tries to link to with readline (now GPLv3) — Lucas Nussbaum <redmine@...>

Bug #2983: Ruby (GPLv2 only) tries to link to with readline (now GPLv3)

10 messages 2010/03/18

[#28907] [Bug #3000] Open SSL Segfaults — Christian Höltje <redmine@...>

Bug #3000: Open SSL Segfaults

19 messages 2010/03/23

[#28924] [Bug #3005] Ruby core dump - [BUG] rb_sys_fail() - errno == 0 — Sebastian YEPES <redmine@...>

Bug #3005: Ruby core dump - [BUG] rb_sys_fail() - errno == 0

10 messages 2010/03/24

[#28954] [Feature #3010] slow require gems in ruby 1.9.1 — Miao Jiang <redmine@...>

Feature #3010: slow require gems in ruby 1.9.1

15 messages 2010/03/24

[#29179] [Bug #3071] Convert rubygems and rdoc to use psych — Aaron Patterson <redmine@...>

Bug #3071: Convert rubygems and rdoc to use psych

10 messages 2010/03/31

[ruby-core:28498] Re: [Feature #2759] Regexp /g and /G options

From: Caleb Clausen <vikkous@...>
Date: 2010-03-05 06:49:48 UTC
List: ruby-core #28498
On 3/4/10, NARUSE, Yui <naruse@airemix.jp> wrote:
> But it is not perfetct; those regexp can't be marshalized.
> % ./ruby
> -e'Marshal.load(Marshal.dump(Regexp.new(%q/(a)(?<n>n)\\1\\k<n>/,256)))'
> -e:1:in `load': numbered backref/call is not allowed. (use name):
> /(a)(?<n>n)\1\k<n>/ (RegexpError)
>         from -e:1:in `<main>'
>
> You still think fixing Marshal should be easy.
> But in marshal.c:
>   case T_REGEXP:
>     w_uclass(obj, rb_cRegexp, arg);
>     w_byte(TYPE_REGEXP, arg);
>     {
>       int opts = rb_reg_options(obj);
>       w_bytes(RREGEXP_SRC_PTR(obj), RREGEXP_SRC_LEN(obj), arg);
>       w_byte((char)opts, arg);
>     }
> You know the value of this option is 256,
> but current code marshalize the option as char...
> It is difficult to extend this with compatibility.

I'm glad you're being careful and thinking about stuff like this,
because I wouldn't have known it might be a problem.

Can't you rewrite that as something like this:

   /*untested, intended more as an example*/
   case T_REGEXP:
     w_uclass(obj, rb_cRegexp, arg);
     {
       int opts = rb_reg_options(obj);
       if (opts<=0xFF)
         w_byte(TYPE_REGEXP, arg);
       else
         w_byte(TYPE_WIDEREGEXP, arg);
       w_bytes(RREGEXP_SRC_PTR(obj), RREGEXP_SRC_LEN(obj), arg);
       if (opts<=0xFF)
         w_byte((char)opts, arg);
       else
         w_int(opts, arg);
     }

That is, use the old format if the regexp options will fit in a byte,
else use a new format with a wider field for options. There'd be
similar logic on the unmarshal side. This new regexp format would be
unreadable on older ruby versions, but then they won't know what to do
with 256 in the options field anyway, so there's no loss there.

In This Thread