Throw exceptions with invalid hex WKB of unexpected size

[Mike Taves]

PostGIS' parser does this nicely, where if a WKB hex string does not match the expected size, it will raise an ERROR. GEOS' WKBReader.cpp only throws ParseException for invalid HEX char, but not for expected size. A similar request is also valid for the istream reader (too many or too few bytes).

For example, with POINT(2 1):

valid: 01010000000000000000000040000000000000F03F

truncated: 01010000000000000000000040000000000000F03

• GEOS: POINT (2 5.659799424266695e-73)
• PostGIS: ERROR: Invalid hex string, length (41) has to be a multiple of two!

extended: 01010000000000000000000040000000000000F03FF

• GEOS: POINT (2 1)
• PostGIS: ERROR: Invalid hex string, length (43) has to be a multiple of two!

The truncated example is the most realistic situation, as it may have arrived to GEOS via a character array that was too small.

[Mike Taves]

I should add that a very easy check to implement is to ensure that there is an even length of hex chars. As shown above with "multiple of two" errors, only even string lengths are valid hex strings. Odd-length strings are invalid. This check can be done before any further analysis of the WKB structure. Here are some more comparisons.

truncated valid hex, invalid WKB: 01010000000000000000000040000000000000F0

• GEOS: POINT (2 -1.017458256970193e+236)
• PostGIS: WKB structure does not match expected size!

extended valid hex, invalid WKB: 01010000000000000000000040000000000000F03FFF

• GEOS: POINT (2 1)
• PostGIS: POINT(2 1) (hmm, no error or message this time)

[strk]

The WKBReader::readHEX is indeed not that strict. Actually chances are it would even support newlines in the hex...

[strk]

r3964 in trunk (3.5.0), r3965 in 3.4 branch (3.4.3) -- I don't think it's worth backporting to 3.3 branch.

[strk]

Ticket retargeted after milestone deleted