OSS FUZZ fixes: ptarray fixes

[robe]

I've started an attempt to resolve OSS FUZZ complaints.

Pull request here, for your input.

​https://git.osgeo.org/gogs/postgis/postgis/pulls/15

strk doesn't think my change should have made a difference but I tested two times. without the change segmentation fault with change no segmentation fault.

My assumption is because the *_cp functions do more checking and internal does pretty much none.

In hind-sight I probably could have achieved the same affect by swapping out calls to getPoint2d_internal with getPoint2d_cp without having to resort to declaring POINT2D variables.

I still need to get the extra CPP flags enabled to confirm I got all the issues in this bug ticket.

​https://oss-fuzz.com/v2/testcase-detail/4733660446064640?noredirect=1

Since it complained about others

note based on strk's urging, I switched back to using the earlier functions, but doing a pointer and npoints check.

[strk]

Beside checking, doesn't the *_cp version leaves the passed pointer untouched when the point is empty ? In that case, are you comparing arbitrary POINT values ? (as you never really initialize those points, rigth?)

[robe]

Here is the thing I don't get about cc'.

The _cp code returns 0 in case of empty I presume, but what exactly does that mean when return type expected is const POINT2D.

​http://postgis.net/docs/doxygen/2.4/da/de7/liblwgeom_8h_ab943e4f240882f2b76341a2948778d2d.html#ab943e4f240882f2b76341a2948778d2d

Do all 0s evaluate as nothing?

if ( ! pa ) return 0;
  488 
  489         if ( (n<0) || (n>=pa->npoints))
  490         {
  491                 lwerror("getPoint2D_const_p: point offset out of range");
  492                 return 0; /*error */
  493         }

As far as lwerror goes, doesn't that always hold execution of the function. I've never seen an lwerror show up in PostgreSQL where my function wasn't killed. So I presume I don't need to worry about catching that.

[strk]

The return from that function is an object *pointer* so 0 means NULL pointer. What happens upon calling lwerror depends on the error handler installed. PostGIS installs an handler that interrupts the flow, but other clients (unit tests, fuzzers, foreign clients when allowed) are free to install an handler that continues execution, so it is important not to assume loss of flow on error.

[robe]

In 15487:

Credit to OSS-Fuzz
​https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2590

References #3786 for PostGIS 2.4/trunk

[robe]

there are still more it seems so I'll backport these and then check on the others why those dind't automatically close.

[robe]

In 15489:

OSS-Fuzz detected issues with ptarray
References #3786 for PostGIS 2.3 (for 2.3.4)

[pramsey]

All ossfuzz postgis issues seem done ​https://bugs.chromium.org/p/oss-fuzz/issues/list?can=2&q=postgis&colspec=ID+Type+Component+Status+Proj+Reported+Owner+Summary&cells=ids