GNU nano - Bugs: bug #60263, nano wrongly designates U+FDD0 to...
You are not allowed to post comments on this tracker with your current authentication level.
bug #60263: nano wrongly designates U+FDD0 to U+FDEF as invalid
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Sat 20 Mar 2021 04:36:54 PM UTC | ||
Severity: | 2 - Minor | Status: | Fixed |
Assigned to: | bens | Open/Closed: | Closed |
Wed 24 Mar 2021 07:30:42 PM UTC, comment #1: |
Benno Schulenberg <bens> |
Sat 20 Mar 2021 04:36:54 PM UTC, original submission:
To reproduce, run 'nano --ignore' and type: M-V 00fdd1
|
Benno Schulenberg <bens> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2021-04-30 | bens | Open/Closed | Open | Closed | |
2021-03-24 | bens | Status | In Progress | Fixed | |
2021-03-22 | bens | Status | None | In Progress | |
Assigned to | None | bens |
Powered by Savane 3.13-02a9.
Corresponding source code
Fixed in git, commit de816840, by dropping the checks for the 66 non-characters from is_valid_unicode().
But... now I see that is_valid_unicode() is entirely superfluous, because mblen() and mbtowc() already consider the byte sequences that encode U+D800 to U+DFFF as invalid (returning -1), and glibc wrongly does not consider codes above U+10FFFF as invalid (see bug #60262). Verbatim input already rejects anything above U+10xxxx, right at the input stage, and is_valid_unicode() comes far too late in display_string() because breadth() and wideness() have already (falsely) determined that codes above U+10FFFF are each a single character (instead of invalid series of four or five or six bytes).