JamesParrott
commented
9 months ago It would be good to prevent overflows, but there's also an argument that this use case is not supported.
Firstly: Is there a need for NaN in computational geometry(*)? NaN (DoubleNotANumber) is actually used internally to initialise some shapes.
Secondly Do any users need to define quantities, both to a precision of 1 unit, and also describe negative values as large as -2.2E+155 ?
The Planck length is 10^-35m, and the size of the observable universe is 10^27m.
Internally, strtod is used in the tokenizer. The WKT parser functions return doubles. If 64 bit doubles are available, they should support numbers as large as 10^308. So Gabe, if you haven't found the limits of floating point precision (or of your test machine), there's a possibility something more interesting is causing the error. But this is an extreme edge case.
NaN
(*) There is code in Geos to parse NaN (and even infinity). However, the libgeos WKT spec doesn't give any examples of NaN, and everything boils down to <Number>. NaN is a valid value according to some floating point standards, but it's entirely reasonable to conclude that by definition (the clue is in the name): NaN is not a <Number>.
https://libgeos.org/specifications/wkt/
The (OG) OGC WKT spec (7.2.1 - 7.2.2) excludes NaN:
<point> ::= <x> <y>
<x> ::= <signed numeric literal>
<signed numeric literal> ::= {<sign>}<unsigned numeric literal>
<unsigned numeric literal> ::= <exact numeric literal>|<approximate numeric literal>
<exact numeric literal> ::= <unsigned integer>
{<decimal point>{<unsigned integer>}}
|<decimal point><unsigned integer>
<approximate numeric
literal> ::=
<mantissa>E<exponent>
<mantissa> ::= <exact numeric literal>
<exponent> ::= <signed integer>
<exact numeric literal> ::= <unsigned integer>
{<decimal point>{<unsigned integer>}}
|<decimal point><unsigned integer>
<signed integer> ::= {<sign>}<unsigned integer>
<unsigned integer> ::= (<digit>)*
<digit> ::= 0|1|2|3|4|5|6|7|8|9
https://www.ogc.org/standard/sfa/ https://portal.ogc.org/files/?artifact_id=25355
gabe-sherman
pramsey
I am an undergraduate student exploring automatic fuzzing harness generation for open source api's. I found that executing geosop instrumented with asan with these arguments:
./geosop -a "GEOMETRYCOLLECTION(POINT(0 0 59.083333333333336), POINT(1 1 59.083333333333336), LINESTRING(2 4 111 1, 2 223 22 2), POLYGON((42 -2.222222223222222e+155 111 1, 2 3 1 1, 2 4 111 NaN, 42 -2.222222223222222e+155 111 NaN)), POLYGON((2.2222222212222224e+149 4 111 1, 42 -2.222222222222222e+149 22 2, 2 4 111 1, 22 2222222222222223 22 NaN, 2.2222222212222224e+149 4 111 NaN)))" -b "LINESTRING (1.6409301755752343e+149 -5.298190649085575e+148, 1.6666666660752404e+149 -5.55555555396982e+148)" intersectionresults in a heap-buffer-overflow.
Test Environment Ubuntu 22.04, 64bit Using the Latest version: https://github.com/libgeos/geos/commit/0aef713ac930e7247c50a1ae720c36f0f0bf790a