Re: [Boost-users] Boost.Archive: Infinite recursion indinkumware.hpp

From: Daniel Krügler (dsp_at_[hidden])
Date: 2005-08-30 01:28:25

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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users