`graphic-char-p' t for non-ASCII non-printable Unicode code-points esp. #\UFFFF #\UFFFE
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Confirmed
|
Low
|
Unassigned |
Bug Description
The doc for `graphic-char-p' is kinda misleading (esp. in current UTF-8 era):
,----
| "The argument must be a character object. GRAPHIC-CHAR-P returns T if the
| argument is a printing character (space through ~ in ASCII), otherwise returns
| NIL."
`----
Might this be otherwise better stated as:
,----
| "The argument must be a character object. GRAPHIC-CHAR-P returns T if the
| argument is an ASCII printable character with char-code _not_ in the integer
| range 0-31 nor 128-159 inclusive, (e.g all but Space through ~ in ASCII).
| Whether characters outside these bounds are printable is encoding system/
| locale dependent and the return value should not be relied upon in Portable Code. "
`----
Likewise, my current SBCL "1.0.42.25" returns true with `graphic-char-p' with
UTF-8 `code-char's from the so called UCS "non-characters" at the top of each
plane (e.g. the *FFFE and *FFFF codes).
In particular, some care should be taken with the two at the top of the
so-called "Private Use Area" (PUA) e.g. :
(code-char 65534) and (code-char 65535)
(let ((gthr (loop for a downfrom 160 to 0 collecting a)))
(loop for b in (nreverse (append '(65534 65535) gthr))
collecting (list :char b
:is-graphic (graphic-char-p (code-char b))
--
/s_P\
Changed in sbcl: | |
importance: | Undecided → Low |
status: | New → Confirmed |
tags: |
added: library removed: ascii code-char graphic-char-p ucs utf-8 |