polygonToCells CLI silently drops vertices when whitespace precedes a coordinate's closing bracket

Open Beginner friendly
  • Is something wrong?
#1,308 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c, shell
Domain
cli

Research direction

Start in polygonStringToGeoPolygon in src/apps/filters/h3.c, where the coordinate scanner uses the format %lf%*[, \n]%lf%1[]]%n; the ] scanset does not skip whitespace after the second number, so the pair is dropped. Reproduce with h3 polygonToCells -r 5 on the square and the spaced variant, and compare the cell counts (66 vs 34). Done means whitespace before a closing bracket parses the same as without it, and a truly malformed coordinate is rejected rather than silently skipped; also check h3 greatCircleDistanceKm -c '[[0,0],[0,1 ]]'.

Written by the indexing model from the issue text.

Description

On master 15920096, adding one space to a valid coordinate array changes the polygon's covering cells without an error.

Reproduction

Using the native CLI built from unchanged source with GCC 14.2.0 on Linux:

h3 polygonToCells -r 5 -p '[[0,0],[0,1],[1,1],[1,0]]' > square.json
h3 polygonToCells -r 5 -p '[[0,0],[0,1],[1,1 ],[1,0]]' > spaced.json
h3 polygonToCells -r 5 -p '[[0,0],[0,1],[1,0]]' > triangle.json
python3 - <<'PY'
import json
square = set(json.load(open('square.json')))
spaced = set(json.load(open('spaced.json')))
triangle = set(json.load(open('triangle.json')))
print(len(square), len(spaced), len(triangle))
print(spaced == square, spaced == triangle)
PY
# 66 34 34
# False True

All three CLI invocations exit with status 0. The second input describes the same four corners as the first, but its result exactly matches the triangle with [1,1] removed. This can silently change the covered region when coordinate arrays are reformatted.

Expected

Whitespace between a number and ] should not change the coordinates or covering cells. If a coordinate cannot be parsed, the CLI should reject the input rather than silently omit it.

Investigation and controls

The coordinate scanner in polygonStringToGeoPolygon uses %lf%*[, \n]%lf%1[]]%n. The scanset for ] does not skip whitespace after the second number; the coordinate is not appended when that conversion fails.

I reproduced the same 34-cell result with a tab, line feed or carriage return before that closing bracket. Spaces after coordinate brackets preserve the expected 66-cell result. Python's JSON parser confirms that the four whitespace variants describe the same coordinate array as the original.

The same parser also affects distance input: h3 greatCircleDistanceKm -c '[[0,0],[0,1]]' prints 111.1950519752, while adding a space before the second coordinate's closing bracket produces Only two pairs of coordinates should be provided.

This is a short inline-input case, not the 1500-byte file-chunk boundary fixed by #1249. No library API change or patch is proposed here. Validation is limited to the native Linux/GCC CLI and the controls above; I have not run the full CTest suite or tested other platforms.

Dominant language
C
Stars
6.7k
Forks
658
Avg merge
5d 21h
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uber/h3

All issues in uber/h3

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.