Selon Ari Jolma <[email protected]>: > Even, > > I've uploaded a version, which fixes these. I added a note that GEOS is > required, as these probably segfault without it (the methods return > NULLs and not geometries).
Hi, Hum, I didn't think at crashes. I thought that the algorithm would just nicely fail. But yes indeed you are right, reviewing the code, there would be NULL derefs, so I'd suggest adding a preliminary call to OGRGeometryFactory::haveGEOS() to exit early if it returns FALSE. This will save crashes to people running the test suite on a build without GEOS support. I'm also wondering if there would not be cases where the GEOS routines could return NULL geometries. Looking at the implementation of GEOSIntersection_r() (and other methods) in http://svn.osgeo.org/geos/trunk/capi/geos_ts_c.cpp , in case an exception is thrown in GEOS C++ code, it will be caught by the GEOS C API and returned as a NULL pointer to the caller. So I suspect that if invalid geometries are processed, we could get a NULL geometry, and it might be appropriate to handle it gracefully. Looking quickly at the patch, I think it would be for the occurrences of OGRGeometry *x_geom_diff_new (2 places) in OGRLayer::Union(), same in ::Identity(), in ::Update() and ::Clip(). Best regards, Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
