[geos-devel] What's the intent of 'assert(!"should never be reached")'?

Sean Gillies sean.gillies at gmail.com
Wed Oct 7 08:52:32 PDT 2015


On Wed, Sep 30, 2015 at 12:04 PM, Sandro Santilli <strk at keybit.net> wrote:
> On Tue, Jul 07, 2015 at 12:12:54PM -0600, Sean Gillies wrote:
>> There are three places in GEOS where this assertion appears
>>
>>
>> https://github.com/libgeos/libgeos/blob/c9d94c2ebb68b6b679f03dc7eabebfcd39136def/src/index/strtree/AbstractSTRtree.cpp#L371
>>
>> and two them have been tripping up Shapely users on OS X. I've found that
>> rebuilding GEOS with --disable-cassert solves the user problems: no assert
>> exceptions raised and no other program crashes.
>>
>> My question: what is the intent of these statements? If they can be safely
>> ignored, as I'm doing, should they not be disabled by default?
>
> Unless you're extending GEOS by subclassing a Boundable, such an
> assert would indicate a compile issue.
>

Thanks for the reply, Sandro. I've switched over to --disable-cassert
(-DNDEBUG) in my library builds but am still falling through the tests
above that assert at runtime in a particular case:

- on OS X
- calling unary union
- loading libgeos_c.dylib via Shapely *after* loading libgeos_c.dylib
(using a different path) via a different Python C extension module
(Fiona).

As reported at https://github.com/Toblerity/Fiona/issues/276, there's
a unary union operation that returns a multipolygon when Shapely is
imported first and an empty geometry collection when Shapely is
imported second.

Are there inherent pitfalls in loading libgeos twice on OS X?

-- 
Sean Gillies


More information about the geos-devel mailing list