[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

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