Opened 5 years ago

Closed 3 years ago

#972 closed defect (fixed)

C API: Possible divide by zero and use of uninitialized variables

Reported by: macdrevx Owned by: strk
Priority: major Milestone: 3.10.0
Component: C API Version: main
Severity: Unassigned Keywords:
Cc:

Description

Two of the functions in the C API may include the possibility of divide by zero or use of uninitialized variables:

    double
    GEOSProjectNormalized_r(GEOSContextHandle_t extHandle, const Geometry* g,
                            const Geometry* p)
    {

        double length;
        GEOSLength_r(extHandle, g, &length);
        return GEOSProject_r(extHandle, g, p) / length;
    }


    Geometry*
    GEOSInterpolateNormalized_r(GEOSContextHandle_t extHandle, const Geometry* g,
                                double d)
    {
        double length;
        GEOSLength_r(extHandle, g, &length);
        return GEOSInterpolate_r(extHandle, g, d * length);
    }

In the first function, length is not guaranteed to be initialized within GEOSLength_r. In the case where it's not, the function still proceeds to use it on the next line. Does the C++ compiler automatically initialize it to zero when it's declared?

Even if it is initialized, is there a possibility of a divide by zero?

Similarly, in the second function, length is still used even if it's not initialized.

Proposed solution:

1) Handle error responses from GEOSLength_r and return early, signaling that an error has occurred. 2) Additionally handle the possibility that length is 0 in the first function.

Change History (3)

comment:1 by dbaston, 5 years ago

I don't think length is guaranteed to be initialized to zero, so this should be done explicitly, although I'm not sure if GEOSLength is capable of generating an error for non-null inputs in practice.

comment:2 by pramsey, 3 years ago

Milestone: 3.10.0

comment:3 by pramsey, 3 years ago

Resolution: fixed
Status: newclosed

Fix seems to have been committed.

Note: See TracTickets for help on using tickets.