On Thu, 19 Jun 2003, Rasputin wrote:

> * Martin DeMello <martindemello / yahoo.com> [0636 20:36]:
> > Mark Wilson <mwilson13 / cox.net> wrote:
> > > On Wednesday, June 18, 2003, at 01:55 PM, Martin DeMello wrote:
> > >
> > >> Would including readers for older marshal formats somewhere in the
> > >> distribution make sense? I can definitely imagine scenarios where my
> > >> marshalled data might outlive my ruby version.
> > >
> > > Or better yet (perhaps), an "on-the-fly" converter of older formats to
> > > the newer format.
> >
> > I'm unconvinced this is better - we don't want to encourage data to hang
> > around in the old format, after all.
>
> Is there currently a 'format version' field recorded with the
> object somewhere? That lets future generations decide for you.
>
As this indicates

$ ruby -v -e 'p Marshal.dump(nil).unpack("H*")'
ruby 1.8.0 (2003-06-14) [i386-mingw32]
["040830"]

$ ruby -e 'p Marshal.dump(true).unpack("H*")'
["040854"]

$ ruby -e 'p Marshal.dump(1).unpack("H*")'
["04086906"]

the first two bytes are version info of some sort. Taking a look in
marshal.c reveals the major active lines:

    w_byte(MARSHAL_MAJOR, &arg);
    w_byte(MARSHAL_MINOR, &arg);

    rb_ensure(dump, (VALUE)&c_arg, dump_ensure, (VALUE)&arg);

    return port;
}

and

#define MARSHAL_MAJOR   4
#define MARSHAL_MINOR   8

which indicates that the first byte is the major rev number and the 2nd
one is the minor rev number. Looking a bit further indicates that the 3rd
byte seems to be used to indicate class of the object => nil/true/false
need only three bytes to be uniquely spec'ed. Looking even further (ok
last time ;)) reveals that Marshal.load bails out if major rev is not same
as the expected one or if minor is higher than expected one.

Would be interesting to know how many minor rev's there has been for the
major rev numbers before 04?

Regards,

Robert