Subject: Re: [geometry] Fwd: Found bug in Boost::geometry
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-10-17 08:55:46
Thanks for forwarding. In case of overflow we either have to promote
automatically to a larger calculation type (larger than int would mean
64bit int), or that the user specifies that specificly...
If users really want to "using coordinates very close to MIN/MAX values
available for 4-byte integer", yes then the calculation type definitly
has to be 64 bits.
On 17-10-2012 14:27, Mateusz Loskot wrote:
> I received this report about problem with Boost.Geoemtry from Sergey,
> one of SOCI users.
> He asked me if I can forward it to the developers, so here it is:
> (I hope the .cpp file attachment will get through.)
> If this problem is confirmed as a bug, Sergey is willing to submit proper
> report to the Boost Trac.
> ---------- Forwarded message ----------
> From: Sergey Stepanov <net_storm_at_[hidden]>
> Date: 17 October 2012 08:12
> Subject: Found bug in Boost::geometry
> To: Mateusz Loskot <mateusz_at_[hidden]>
> Hello, Mateusz
> I wasn't sure whom shall I contact, but since I know you for your great
> effort in the SOCI development, I decided to ask you first.
> If you know better person to contact, feel free to redirect me.
> Our team found a very specific bug at the Boost::Geometry library.
> Generally speaking on subtraction of two negative integer coordinates,
> those are at the minimum limits we have problem.
> Tracing into boost.geometry core we have found that in the file
> sectionalize.hpp integer overflow happens in the following expression in
> line 118:
> coordinate_type const diff = geometry::get<1, Dimension>(seg) -
> geometry::get<0, Dimension>(seg);
> Here is a file in enclosure, which replicates that bug.
> Or maybe it could be feature which we don`t know about =)
> Stepanov Sergey
> XMPP: netstrom_at_[hidden]
> SKYPE: sergey.y.stepanov
> mobile: +7(921)345-78-22
> Geometry mailing list
Geometry list run by mateusz at loskot.net