Re: [boost] [Serialization] Bizarre bug

Subject: Re: [boost] [Serialization] Bizarre bug
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-08-11 00:43:17

Jarl Lindrud wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:

>>> Another wrinkle in IPC serialization, is that one program may
>>> contain only serialization code for a type T (and not
>>> deserialization), while another program may contain only
>>> deserialization code for type T (and not serialization). If that
>>> makes the programs ill-formed in your view,
>>
>> It doesn't
>>
>>> then I guess one would have to conclude that B.Ser. is not an
>>> appropriate choice for IPC applications.
>>
>> Hence, I would not draw such a conclusion.
>>
>
>
> I think I must profess some skepticism here. In your post on Aug 4
> you wrote "This system is broken for the case where ar << ptr is
> invoked but ar >> ptr isn't", regarding instantiation of pointer
> serialization code.

I never said that the ar >> ptr and ar << ptr have to be in the same
program - and in fact they don't.

program 1 containing only

ar << Tptr

program 2 containing only

ar >> Tptr

presents no problem.

The problem only occurs when program 1 contains only

ar << T

and program 2 contains

ar >> T
and
ar >> Tptr

But if only program 2 contains ar >> Tptr - how does the
archive it's supposed to read get created?  It can be only
created by a program which also contains ar << Tptr. That
is in order for serialization to make any sense at all both
programs have to  contain exactly the same sequence of
loads and saves.  Hence. they will both either serializations
for the same set of types at compiler time.

The only case where this can occur is where the program
is changed after an archive is created.  And even then it
takes some effort to produce. This is the situation I was
referring to and I include the only example that occured
to me where this would arise in practice.

> And yet that is exactly the situation that would
> arise, when you have request and response objects in an IPC system,
> each containing different sets of user-defined types. Clients
> serialize requests, but they don't deserialize them. And conversely,
> servers deserialize requests, but don't serialize them.

That is not relevant.  The ar >> and ar << don't have to be in
the same program.  They just have to be consistent with each
other.

In the IPC case, the program could only occur when
the recieving program is a later version of the sending version.
That is the same problem - reading an old archive version.

Robert Ramey