Boost.Archive: Infinite recursion in dinkumware.hpp

Robert Ramey wrote:

So should your change be made or not? I really couldn't follow your argument but its an issue on which I'm prepared to rely 100% on the judgement of someone who has considered it in much more detail than I have.

This is a joke, isn't it? ;-) I greatly respect your code, but my personal recommendation is to apply the provided fix, because in my opinion the fix prevents a severe problem which **can** happen on VC6. I added a postscriptum to my first mail, because the reasoning of my first one was unfairly describing the mentioned code branch as causing infinite recursion in every case. I repeat, that this not true, but it is also true, that it will cause infinite recursion, iff the argument is equal to std::numeric_limits<boost::uint64_t>::min() on 2-complement systems. Or to say it simply: This happens on VC6, which is most probably the only affected compiler - you can easily test my assertion, if you have this compiler available. Greetings Daniel

Robert Ramey

Daniel Krügler wrote:

...

Daniel Krügler wrote:

...

The streaming inserter of Boost archive's dinkumware.hpp for boost::int64_t causes indefinite recursion in case of negative arguments. I think the following line inside the else clause should be changed from

os << -t;

to

os << static_cast<boost::uint64_t>(-t);

Greetings from Bremen,

Daniel

I apologize for incomplete information. The streaming inserter does not cause infinite recursion in **general** cases, but only in one special case: If the argument equals std::numeric_limits<boost::uint64_t>::min().

This is a special case, because in 2-complement systems (I think, that is the only audience for that header) negating this value will return a negative number. From a general standpoint of C++ this is one special form of U.B., as described in section 6.2.5 of the C99 standard (I have no older C standard available), but considering the code to be available only for the platform target I **assume** (contradictory opinions anywhere?) that the proposed code, which in general C++ would also cause U.B., uses platform specific behaviour to prevent that case.

Greetinmgs from Bremen,

Daniel Krügler

------------------------------------------------------------------------

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users