-----Original Message----- From: Boost
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:
https://github.com/boostorg/serialization/pull/111/files
which does indeed crash
https://travis-ci.org/boostorg/serialization/jobs/441654483#L2546
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 (https://github.com/boostorg/serialization/pull/111/files ) still fails with the changes introduced by Robert (I'm not sure when they were introduced)? Mike