[#17055] Set#map! vs. map — "David A. Black" <dblack@...>

Hi --

23 messages 2008/06/03

[#17084] Enumerable::Enumerator#with_memo — "Akinori MUSHA" <knu@...>

Hi,

36 messages 2008/06/03
[#17168] Re: Enumerable::Enumerator#with_memo — David Flanagan <david@...> 2008/06/09

Akinori MUSHA wrote:

[#17173] Re: Enumerable::Enumerator#with_memo — "Jeremy Kemper" <jeremy@...> 2008/06/10

On Mon, Jun 9, 2008 at 12:11 PM, David Flanagan <david@davidflanagan.com> wrote:

[#17192] Re: Enumerable::Enumerator#with_memo — "Martin DeMello" <martindemello@...> 2008/06/10

On Mon, Jun 9, 2008 at 10:57 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote:

[#17162] Release Plan: Ruby 1.9.0-2 — SASADA Koichi <ko1@...>

Hi,

44 messages 2008/06/09
[#17254] Re: Release Plan: Ruby 1.9.0-2 — SASADA Koichi <ko1@...> 2008/06/15

Hi,

[#17273] Re: Release Plan: Ruby 1.9.0-2 — Ryan Davis <ryand-ruby@...> 2008/06/16

[#17276] Re: Release Plan: Ruby 1.9.0-2 — Kouhei Sutou <kou@...> 2008/06/16

Hi,

[#17312] Re: Release Plan: Ruby 1.9.0-2 — Ryan Davis <ryand-ruby@...> 2008/06/18

[#17346] Re: Release Plan: Ruby 1.9.0-2 — Kouhei Sutou <kou@...> 2008/06/19

Hi,

[#17167] Mail count in Subject — "Dirk Traulsen" <dirk.traulsen@...>

Hi!

20 messages 2008/06/09
[#17169] Re: Mail count in Subject — "Warren Brown" <warrenb@...> 2008/06/09

All,

[#17171] Re: Mail count in Subject — Urabe Shyouhei <shyouhei@...> 2008/06/10

Warren Brown wrote:

[#17327] A plea for a release process — Brian Ford <brixen@...>

Hi all,

15 messages 2008/06/18

[#17377] Re: Ruby 1.9.0/1.8.7/1.8.6/1.8.5 new releases (Security Fix) — "Bill Kelly" <billk@...>

Hi,

12 messages 2008/06/23

[#17393] URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — "Igal Koshevoy" <igal@...>

All currently available versions of MRI Ruby are either vulnerable to

104 messages 2008/06/24
[#17416] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Urabe Shyouhei <shyouhei@...> 2008/06/28

Sorry for a late reply but I think I've fixed this issue. Can someone

[#17417] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/28

Urabe Shyouhei wrote:

[#17419] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Urabe Shyouhei <shyouhei@...> 2008/06/28

Igal Koshevoy wrote:

[#17422] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/29

Urabe Shyouhei wrote:

[#17426] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Urabe Shyouhei <shyouhei@...> 2008/06/29

Igal Koshevoy wrote:

[#17438] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/29

Urabe Shyouhei wrote:

[#17499] We'll release 1.8.6/1.8.7 this Friday — Urabe Shyouhei <shyouhei@...> 2008/07/02

Hello, I think current 1.8.6/1.8.7 is stable than p230/p22, so I decided

[#17504] Re: We'll release 1.8.6/1.8.7 this Friday — "Vladimir Sizikov" <vsizikov@...> 2008/07/02

Hi Urabe,

[#17506] Re: We'll release 1.8.6/1.8.7 this Friday — Charles Oliver Nutter <charles.nutter@...> 2008/07/02

Vladimir Sizikov wrote:

[#17521] Re: We'll release 1.8.6/1.8.7 this Friday — Urabe Shyouhei <shyouhei@...> 2008/07/03

Charles Oliver Nutter wrote:

[#17544] Re: We'll release 1.8.6/1.8.7 this Friday — Igal Koshevoy <igal@...> 2008/07/03

Urabe Shyouhei wrote:

[#17545] Re: We'll release 1.8.6/1.8.7 this Friday — Charles Oliver Nutter <charles.nutter@...> 2008/07/03

Igal Koshevoy wrote:

[#17806] Re: We'll release 1.8.6/1.8.7 this Friday — "Michal Suchanek" <hramrach@...> 2008/07/16

On 02/07/2008, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

[#17851] Re: We'll release 1.8.6/1.8.7 this Friday — Tanaka Akira <akr@...> 2008/07/19

In article <a5d587fb0807160533r4534fabdg257b4a9523b15f1e@mail.gmail.com>,

[#17852] Re: We'll release 1.8.6/1.8.7 this Friday — Federico Builes <federico.builes@...> 2008/07/19

[#17855] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/19

On Sat, Jul 19, 2008 at 02:18:05PM +0900, Federico Builes wrote:

[#17857] Re: We'll release 1.8.6/1.8.7 this Friday — Federico Builes <federico.builes@...> 2008/07/19

[#17860] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/19

On Sun, Jul 20, 2008 at 12:43:46AM +0900, Federico Builes wrote:

[#17939] Re: We'll release 1.8.6/1.8.7 this Friday — Kurt Stephens <ks@...> 2008/07/24

When will we see a new 1.8.6 release?

[#17940] Re: We'll release 1.8.6/1.8.7 this Friday — Nobuyoshi Nakada <nobu@...> 2008/07/24

Hi,

[#17941] Re: We'll release 1.8.6/1.8.7 this Friday — "Vladimir Sizikov" <vsizikov@...> 2008/07/24

Hi,

[#17945] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/24

On Fri, Jul 25, 2008 at 02:04:15AM +0900, Vladimir Sizikov wrote:

[#17946] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/24

On Fri, Jul 25, 2008 at 04:35:43AM +0900, Jeremy Henty wrote:

[#17947] Re: We'll release 1.8.6/1.8.7 this Friday — Federico Builes <federico.builes@...> 2008/07/24

Jeremy,

[#17948] Re: We'll release 1.8.6/1.8.7 this Friday — Nobuyoshi Nakada <nobu@...> 2008/07/25

Hi,

[#17953] Re: We'll release 1.8.6/1.8.7 this Friday — "Daniel Luz" <dev@...> 2008/07/25

On Thu, Jul 24, 2008 at 9:19 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#17423] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Tanaka Akira <akr@...> 2008/06/29

In article <48662E99.7030508@pragmaticraft.com>,

[#17424] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Federico Builes <federico.builes@...> 2008/06/29

[#17429] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/29

Federico Builes wrote:

[#17431] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — "M. Edward (Ed) Borasky" <znmeb@...> 2008/06/29

Igal Koshevoy wrote:

[#17427] 1.8 release management — Yukihiro Matsumoto <matz@...>

Hi,

43 messages 2008/06/29
[#17455] Re: 1.8 release management — Stephen Bannasch <stephen.bannasch@...> 2008/06/30

Let me describe some simple questions about Ruby 1.8.6 that are not

[#17458] Re: 1.8 release management — Urabe Shyouhei <shyouhei@...> 2008/06/30

For what I know,

[#17547] Re: 1.8 release management — "Wilson Bilkovich" <wilsonb@...> 2008/07/03

On 6/30/08, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#17549] Re: 1.8 release management — Igal Koshevoy <igal@...> 2008/07/03

Wilson Bilkovich wrote:

[#17555] Re: 1.8 release management — "Luis Lavena" <luislavena@...> 2008/07/03

On Thu, Jul 3, 2008 at 4:41 PM, Igal Koshevoy <igal@pragmaticraft.com> wrote:

[#17585] Re: 1.8 release management — Urabe Shyouhei <shyouhei@...> 2008/07/04

Luis Lavena wrote:

[#17588] Re: 1.8 release management — Igal Koshevoy <igal@...> 2008/07/04

Urabe Shyouhei wrote:

[#17589] Re: 1.8 release management — Urabe Shyouhei <shyouhei@...> 2008/07/04

Igal Koshevoy wrote:

[#17591] Re: 1.8 release management — Igal Koshevoy <igal@...> 2008/07/04

Urabe Shyouhei wrote:

[#17593] Re: 1.8 release management — "Vladimir Sizikov" <vsizikov@...> 2008/07/04

Hi,

[ruby-core:17243] [Patch] Support 'canonical' option in Marshal.dump

From: Hongli Lai <hongli@...99.net>
Date: 2008-06-14 07:01:51 UTC
List: ruby-core #17243
Currently Marshal.dump stores Hash entries in no specific order. This 
prevents one from reliably comparing marshalled data in order to 
determine whether a data structure changed. For example, consider the 
following code:

hash = { 'root' => [1, [1, 1.5], 3, 4], 'foo' => 'zort' }
data = Marshal.dump(hash)
data2 = Marshal.dump(Marshal.load(data))

"data != data2" might be possible.

PStore uses an MD5 checksum of the marshalled data to check whether the 
file needs to be updated. Marshal.dump's non-deterministic hash ordering 
gets in the way.

The attached patch adds a 'canonical' argument to Marshal.dump. This 
argument allows Hash entries to be stored in a deterministic order, at 
the cost of a slight performance hit. (PStore will have to be modified 
to take advantage of this, but I'm already working on that.) The patch 
is made against Ruby 1.8.6.

Regards,
Hongli Lai

Attachments (1)

ruby-marshal-dump-canonical.diff (3.33 KB, text/x-diff)
diff --git a/marshal.c b/marshal.c
index 185ace6..8643894 100644
--- a/marshal.c
+++ b/marshal.c
@@ -83,6 +83,7 @@ shortlen(len, ds)
 static ID s_dump, s_load, s_mdump, s_mload;
 static ID s_dump_data, s_load_data, s_alloc;
 static ID s_getc, s_read, s_write, s_binmode;
+static ID id_rehash;
 
 struct dump_arg {
     VALUE obj;
@@ -90,6 +91,7 @@ struct dump_arg {
     st_table *symbols;
     st_table *data;
     int taint;
+    int canonical;
 };
 
 struct dump_call_arg {
@@ -621,6 +623,9 @@ w_object(obj, arg, limit)
 		w_byte(TYPE_HASH_DEF, arg);
 	    }
 	    w_long(RHASH(obj)->tbl->num_entries, arg);
+	    if (arg->canonical) {
+		rb_funcall(obj, id_rehash, 0);
+	    }
 	    rb_hash_foreach(obj, hash_each, (st_data_t)&c_arg);
 	    if (!NIL_P(RHASH(obj)->ifnone)) {
 		w_object(RHASH(obj)->ifnone, arg, limit);
@@ -700,13 +705,21 @@ dump_ensure(arg)
 
 /*
  * call-seq:
- *      dump( obj [, anIO] , limit=--1 ) => anIO
+ *      dump( obj [, anIO] , limit=-1 , canonical=false ) => anIO
+ *
+ * Serializes obj and all descendent objects.
+ *
+ * If +anIO+ is specified, the serialized data will be written to it,
+ * otherwise the data will be returned as a String.
  *
- * Serializes obj and all descendent objects. If anIO is
- * specified, the serialized data will be written to it, otherwise the
- * data will be returned as a String. If limit is specified, the
- * traversal of subobjects will be limited to that depth. If limit is
- * negative, no checking of depth will be performed.
+ * If +limit+ is specified, the traversal of subobjects will be limited
+ * to that depth. If limit is negative, no checking of depth will be
+ * performed.
+ *
+ * If +canonical+ is true, then Hash entries will always be stored in
+ * the same order, regardless of the Hash's internal state. This allows
+ * you to compare data structures by comparing their marshalled
+ * representations.
  *
  *     class Klass
  *       def initialize(str)
@@ -729,18 +742,31 @@ marshal_dump(argc, argv)
     int argc;
     VALUE* argv;
 {
-    VALUE obj, port, a1, a2;
+    VALUE obj, port, a1, a2, a3;
     int limit = -1;
+    int canonical = 0;
     struct dump_arg arg;
     struct dump_call_arg c_arg;
 
     port = Qnil;
-    rb_scan_args(argc, argv, "12", &obj, &a1, &a2);
-    if (argc == 3) {
+    rb_scan_args(argc, argv, "13", &obj, &a1, &a2, &a3);
+    if (argc == 4) {
+	canonical = RTEST(a3);
 	if (!NIL_P(a2)) limit = NUM2INT(a2);
 	if (NIL_P(a1)) goto type_error;
 	port = a1;
     }
+    else if (argc == 3) {
+	if (FIXNUM_P(a2)) {
+	   limit = NUM2INT(a2);
+	   if (NIL_P(a1)) goto type_error;
+	   port = a1;
+	} else {
+	   canonical = RTEST(a2);
+	   limit = NUM2INT(a1);
+	   port = Qnil;
+	}
+    }
     else if (argc == 2) {
 	if (FIXNUM_P(a1)) limit = FIX2INT(a1);
 	else if (NIL_P(a1)) goto type_error;
@@ -766,6 +792,7 @@ marshal_dump(argc, argv)
     arg.symbols = st_init_numtable();
     arg.data    = st_init_numtable();
     arg.taint   = Qfalse;
+    arg.canonical = canonical;
     c_arg.obj   = obj;
     c_arg.arg   = &arg;
     c_arg.limit = limit;
@@ -1480,6 +1507,7 @@ Init_marshal()
     s_read = rb_intern("read");
     s_write = rb_intern("write");
     s_binmode = rb_intern("binmode");
+    id_rehash = rb_intern("rehash");
 
     rb_define_module_function(rb_mMarshal, "dump", marshal_dump, -1);
     rb_define_module_function(rb_mMarshal, "load", marshal_load, -1);

In This Thread

Prev Next