Use NULL and drop SHPLIB_NULLPTR

[schwehr]

SHPLIB_NULLPTR is defined in a number of places. e.g. shpopen.c

#ifdef __cplusplus
#define STATIC_CAST(type,x) static_cast<type>(x)
#define SHPLIB_NULLPTR nullptr
#else
#define STATIC_CAST(type,x) ((type)(x))
#define SHPLIB_NULLPTR NULL
#endif

This doesn't buy much as there is not mechanism in shapelib to build as C++. If the internals are ever converted to C++, then most of the NULLs should be converted to nullptr. The idea of having it both ways just adds complexity. Currently:

grep SHPLIB_NULLPTR *.c | wc -l
245

grep NULL *.c | grep -v SHPLIB_NULLPTR | wc -l
92

@rouault added the cast macros and SHPLIB_NULLPTR in 8ba2778. However, looking at gdal/ogr/ogrsf_frmts/shape, it doesn't currently look like shapelib is being built as C++ in sGDAL

[schwehr]

If there is a need to build shapelib as C++, I think it should just shift to C++ for the library code with a C linkage API. I'd like to hear what drove having it compile as both C and C++.

[schwehr]

I found one place that uses shapelib as C++:

https://github.com/fulcrumapp/shp-ruby/tree/master/ext/shp

[thbeu]

SHPLIB_NULLPTR is defined in a number of places. e.g. shpopen.c

It's now exactly in one place: shapefil_private.h

[rouault]

However, looking at gdal/ogr/ogrsf_frmts/shape, it doesn't currently look like shapelib is being built as C++ in sGDAL

hum, at some point, I certainly did it. Not sure why it didn't materialize in the build system. Anyway now it will per OSGeo/gdal#9436. I've found that building in C++ mode helps finding issues that a C compiler doesn't report.