0

I compiled my program with "clang++ -fsanitize=undefined". When I use the boost::geometry::intersects to check if polygons intersect, it gives me the correct results but also reports the overflow error. My question is, does the overflow error cause the boost::geometry::intersects function error or not? If it leads to the function error, how can I avoid it?

#include <iostream>
#include <vector>
#include <limits>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/io/wkt/wkt.hpp>
#include <boost/geometry/geometries/box.hpp>
#include <boost/foreach.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/geometries/geometries.hpp>
using namespace std; 
typedef boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<long long> > polygon_t;
int main()
{
    bool overlap=false;
    polygon_t polygon1,polygon2;

    boost::geometry::read_wkt(
    "POLYGON((1036000 1000,1036000 1484300,4193980 1484300,4193980 1000,1036000 1000))", polygon1);
    boost::geometry::read_wkt(
    "POLYGON((1120 1484300,1120 1485000,4193980 1485000,4193980 1484300,1120 1484300))", polygon2);

    overlap=boost::geometry::intersects(polygon1,polygon2);
    if(overlap==true)
    {
        cout<<"detect_overlap"<<endl;
    }
    else
    {   
        cout<<"detect_No_overlap"<<endl;
    }

}

Once compiled, I get the error:

/usr/local/include/boost/geometry/strategies/cartesian/intersection.hpp:198:29: 
runtime error: signed integer overflow: 6219269238000 * 1483300 cannot be
represented in type 'long long'

and also the expected output:

detect_overlap
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Hsuan
  • 1
  • 3
  • There is *not* a single statement here that could be C. Please check that you tag the correct language. – Antti Haapala -- Слава Україні May 30 '19 at 05:41
  • 13 digits times 7 digits is around 20 digits (all decimal), which is too big for (signed) integer arithmetic on most machines (`6219269238000 * 1483300 = 9225042060725400000`. The value needs more than 63 bits (but less than 64), so it could be represented if one or both terms is of type `unsigned long long`. – Jonathan Leffler May 30 '19 at 05:57
  • I have change the tag,thanks. – Hsuan May 30 '19 at 05:58
  • So the overflow error may lead to function error? – Hsuan May 30 '19 at 06:00
  • Why do you refuse to accept a [tag:c++] tag? You've removed it twice, when it is clearly the most relevant language tag. Your question will get a far wider audience if it is tagged with [tag:c++] and [tag:boost-geometry] than if you omit [tag:c++]. – Jonathan Leffler May 30 '19 at 06:00
  • Because the input coordinate point may be negative,I can't use unsigned long long – Hsuan May 30 '19 at 06:01
  • Why not use `double`? Why not make sure that the strings represent floating point numbers? – Jonathan Leffler May 30 '19 at 06:02
  • If I use [double] it will give me another error: [/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/ios_base.h:96:24: runtime error: load of value 4294963199, which is not a valid value for type 'std::_Ios_Fmtflags'] [/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/bits/ios_base.h:76:67: runtime error: load of value 4294963199, which is not a valid value for type 'std::_Ios_Fmtflags'] – Hsuan May 30 '19 at 06:06
  • Well, that might be a better question — why do I get `std::_Ios_Fmtflags` errors when I use `double` with `boost::geometry::…`? It isn't clear why using `double` numbers would lead to invalid values being passed to the formatting code. – Jonathan Leffler May 30 '19 at 06:08
  • Also, have you tried testing two non-intersecting polygons to see whether you get a similar overflow but also a correct result? It might be purely accidental that you get the 'right' answer for two intersecting polygons. – Jonathan Leffler May 30 '19 at 06:11
  • I have try to test you say,but I found that I couldn't find two non-intersecting polygons and there was overflow. – Hsuan May 30 '19 at 06:15
  • So that means that the overflow error that's reported makes the calculations unreliable — which is not very surprising; that's what the error message implies. I've no idea how those numbers are created from the data, but clearly, you need to reduce their magnitude to be safe(r). Or find out how to use `double` for the data. – Jonathan Leffler May 30 '19 at 06:23

0 Answers0