Boost logo

Boost Users :

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.



> 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;
>>>os << static_cast<boost::uint64_t>(-t);
>>>Greetings from Bremen,
>>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
>>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]

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at