Recognize blank-padded numeric strings as strnums - #573
Conversation
POSIX defines a numeric string as text that looks like a number after ignoring leading and trailing blanks, and gawk compares such input numerically, so a record like " 12 " must compare equal to 12. JRT.isParseableNumber now skips leading whitespace and accepts trailing whitespace around the numeric token, and StrNum.parseDoubleValue trims the same whitespace before parsing, so recognition and parsing move together. Blank-only text, internal blanks, trailing non-numeric text, and string constants remain non-numeric, as POSIX specifies. Fixes #571 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da6d83e39e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| while (start < length && Character.isWhitespace(value.charAt(start))) { | ||
| start++; | ||
| } | ||
| int end = numericPrefixEnd(value, start, decimalSeparator); | ||
| return end > start && isBlankToEnd(value, end); |
There was a problem hiding this comment.
When an input-derived value is padded with Java-only whitespace such as U+2003 EM SPACE or U+001C FILE SEPARATOR, Character.isWhitespace causes it to be recognized and trimmed as a number. For example, "\u200312\u2003" now compares equal to 12, whereas gawk 5.2.1 under C.UTF-8 reports it as a non-equal string; this can change comparisons and truthiness for Unicode input. Use the AWK/gawk whitespace set for both the leading scan and trailing check rather than Java's broader predicate.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This divergence is deliberate, per Jawk's compatibility policy: on locale-dependent edges Jawk applies Java semantics rather than emulating the C locale's isspace set — the same way JRT.toDouble already skips leading Unicode whitespace in string-to-number conversion. Keeping recognition on Character.isWhitespace keeps it consistent with conversion and guarantees everything recognized also parses (JRT.trimWhitespace uses the same predicate). Documented the divergence in the deliberate-differences list on the index page and pinned it with a test in 5e81af5.
Character.isWhitespace is wider than the C isspace set gawk relies on, so Unicode spaces such as EM SPACE pad a numeric string in Jawk but not in gawk. This is deliberate: Jawk applies Java semantics on such locale-dependent edges, consistently with the leading-whitespace skip in string-to-number conversion. Document the divergence on the index page and pin it with a test so recognition and parsing stay aligned on the wider set. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@codex please review again |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Fixes #571.
What changed
POSIX defines a numeric string as text that looks like a number after ignoring leading and trailing blanks, and gawk compares such input numerically. Jawk's strnum recognition rejected any blank, so
' 12 ' == 12fell back to string comparison on$0,getline varresults,split()pieces with a non-default separator, and preassigned variables.JRT.isParseableNumbernow skips leading whitespace and accepts trailing whitespace around the numeric token. Blank-only text, internal blanks (" 1 2 "), and trailing non-numeric text (" 12x ") are still rejected, and string constants are unaffected (they never were strnums).StrNum.parseDoubleValuetrims the same whitespace (newJRT.trimWhitespace) before parsing, so recognition and parsing move together —Double.parseDouble/BigDecimaldon't accept every characterCharacter.isWhitespacedoes.Character.isWhitespace, consistent withJRT.toDouble's leading-skip. gawk uses Cisspace, so\f/\vpadding also counts there (verified empirically); POSIX's space/tab blanks are a subset of both.Verification
Every expectation was checked against gawk 5.0 first:
JRTComparisonNumberTest(recognition, locale separator, blank-paddedStrNumparsing, uninitialized-vs-" 0 ").StrNumSemanticsTest: the issue's repro ($0 == 12on" 12 "),getline varfrom a padded file,split()pieces, preassignments, truthiness of" 0 "/" 12 ", and the pinned non-strnum cases (internal blanks," 12x ", blank-only records, string constants).mvn verifygreen: 840 unit tests, 0 failures; checkstyle/pmd/spotbugs clean.mainworktree baseline: the failing-testcase sets are identical (141 both sides) — no regressions, and no fixtures move because the gawk strnum fixtures don't exercise blank padding (they already passed).Unreleasedinbehavior-changes.md.🤖 Generated with Claude Code