Fix \u{X…XXXXXX} description: a hexadecimal value, not "1 to 6 bytes" - #3975
Fix \u{X…XXXXXX} description: a hexadecimal value, not "1 to 6 bytes"#39751t1sCooL wants to merge 2 commits into
Conversation
Sorry, something went wrong.
|
|
Sorry, something went wrong.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 81024abeaf
ℹ️ About Codex in GitHubYour 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".
Sorry, something went wrong.
| - `\u{X…XXXXXX}` | ||
|
|
||
| `X…XXXXXX` must be a hexadecimal value of 1 to 6 bytes between `0` and `10FFFF` (the highest code point defined by Unicode). This notation allows us to easily represent all existing Unicode characters. | ||
| `X…XXXXXX` must be a hexadecimal value of 1 to 6 hex digits between `0` and `10FFFF` (the highest code point defined by Unicode). This notation allows us to easily represent all existing Unicode characters. |
There was a problem hiding this comment.
Allow leading zeroes beyond six hex digits
ECMAScript does not impose a six-character limit on the contents of a braced Unicode escape; it only requires the resulting numeric value to be at most 0x10FFFF. For example, "\u{0000001}" is valid and produces code point 1, so this wording incorrectly rejects valid escapes containing more than six digits due to leading zeroes. Describe the value as having at most six significant hex digits, or omit the digit-count limit.
Useful? React with 👍 / 👎.
Sorry, something went wrong.
|
Good catch, thanks — fixed in 17ba8ad. The spec doesn't cap the number of hex digits inside \u{…}; it only requires the resulting value to be at most 0x10FFFF. So "\u{0000001}" is valid and yields code point 1, which the "1 to 6" wording wrongly rejected. I dropped the digit-count clause altogether rather than saying "at most six significant digits" — the value range already carries all the information that matters:
Note the original text was inaccurate on a second count as well: it said "1 to 6 bytes", where the escape actually takes hex digits. That was the reason for this PR in the first place. The same sentence in the Russian translation is updated in javascript-tutorial/ru.javascript.info#2175 to keep the two in sync. |
Sorry, something went wrong.
The \u{X…XXXXXX} escape takes hexadecimal digits, not bytes: the maximum code point 10FFFF is 6 hex digits, which is 3 bytes.
Following the review feedback, the digit-count limit is now dropped as well. The spec does not cap the number of hex digits inside \u{…} — it only requires the resulting value to be at most 0x10FFFF. For instance "\u{0000001}" has seven digits and is perfectly valid, so "1 to 6 digits" would have been inaccurate in its own way. The value range alone conveys everything that matters.
Spotted via the Russian translation (javascript-tutorial/ru.javascript.info#2124), where the same wording was faithfully translated along with the mistake. The Russian side is updated in javascript-tutorial/ru.javascript.info#2175.