Boost logo

Boost :

Subject: [boost] "peer reviewed" - Rights and responsibilities of maintainers
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-16 15:49:22

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
> Sent: Tuesday, October 16, 2018 5:22 PM
> On 10/16/18 8:11 AM, Peter Dimov via Boost wrote:
> > Robert Ramey wrote:
> >> On 10/16/18 7:23 AM, Peter Dimov via Boost wrote:
> >>
> >> >
> >> >
> >> > which does indeed crash
> >> >
> >> >
> >> >
> >> > That's easy enough to follow and does show a legitimate problem, in
> >> my > opinion, although Robert refuses to acknowledge it for some reason.
> >>
> >> The test does not show anything at all. It's ill conceived.
> >
> > What is ill-conceived about it? It's a minimal example of two shared
> > libraries each using Serialization. As Alexander says, it's a simplified
> > version of a crash they had in one of their projects.
> First of all, the test changes every time I look at it. It's hard to
> follow.

If you keep saying that the test is bad / irrelevant, it is no wonder
the author changes the code to improve it.

> On the last version I looked at - since no there is not
> BOOST_CLASS_EXPORT(class name) invoked, there are no indexed entries in
> the extended type info tables so get_key() should return null under any
> circumstances.

If I understand this correctly, the purpose of the test is to show that the
application crashes. In that case, the return value is completely irrelevant.

If you think that crash is not the fault of Boost.Serialization (e.g. because
it is used wrongly), then it would be helpful to explain what you believe to
be the actual reason for the crash.

What I don't know: Is there a travis build that shows that the test from Flamefire
( ) still fails
with the changes introduced by Robert (I'm not sure when they were introduced)?


Boost list run by bdawes at, gregod at, cpdaniel at, john at