childPosToCell CLI silently changes zero-padded child positions
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- Half a day
- Newbie friendliness
- 45/100
Research direction
The position is parsed with PRIi64 in the childPosToCell scanner in src/apps/filters/h3.c, around lines 1187-1195, so padded decimal input is read as octal. Start by reproducing the two commands from the issue against the native CLI and comparing with cellToChildPos. Done means a decided behaviour (decimal parsing or rejection of padded and hex input) with a test added to the CLI test suite and the maintainers' compatibility choice recorded in the issue.
Written by the indexing model from the issue text.
Description
Reproduction
On master at 15920096, with the CLI built from unchanged source using GCC 14.2:
h3 childPosToCell -c 85283473fffffff -r 7 -p 8 -f newline
# 872834709ffffff
h3 childPosToCell -c 85283473fffffff -r 7 -p 08 -f newline
# 872834700ffffff
Both exit successfully. Passing the two cells back to h3 cellToChildPos -c <cell> -r 5 gives positions 8 and 0 respectively. Similarly, 10 and 010 round-trip to 10 and 8; 42 and 042 round-trip to 42 and 34. A script that pads positions can therefore select a different cell without an error.
Expected behavior / compatibility question
The help describes --position as a child position without specifying the numeral base. I expected padded decimal values to select the same child, or to be rejected rather than silently selecting a different one.
The position scanner uses PRIi64 (%i conversion), which recognizes an octal prefix and also accepts explicit hex: 0x10 selects position 16 today. Is C-style base detection intended here, or should the CLI treat padded inputs as decimal? If decimal is intended, should explicit hex remain supported for compatibility?
Verified with the native CLI on Linux. No parser change or CTest run yet.
- Dominant language
- C
- Stars
- 6.7k
- Forks
- 658
- Avg merge
- 5d 21h
- Merged PRs (30d)
- 12
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from uber/h3
-
polygonToCells CLI silently drops vertices when whitespace precedes a coordinate's closing bracketOpen
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
cellsToMultiPolygon: int64_t counts are narrowed to int struct fields without a bounds checkPossibly taken @madib06ops claimed this 30 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 Half a day Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 50/100
Maintainers usually reply within 1 day
Similar issues
-
Status: Opened
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FriendsofECCE/ECCE#1018 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
immortalwrt/immortalwrt#2522 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
severity: low
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
luainkernel/lunatik#2530 ·
Maintainers usually reply within 1 day