summaryrefslogtreecommitdiff
path: root/utf8.c
diff options
context:
space:
mode:
authorKarl Williamson <public@khwilliamson.com>2012-03-19 14:48:51 -0600
committerKarl Williamson <public@khwilliamson.com>2012-03-19 18:23:44 -0600
commitd0460f306d2b79d09a9e5694f9f72c50a2481b83 (patch)
tree8bacaf9ed0a384f584b1d7104b3c84241bd9b6b6 /utf8.c
parenta1433954f53591f4446530df211b86112c6c2446 (diff)
downloadperl-d0460f306d2b79d09a9e5694f9f72c50a2481b83.tar.gz
utf8.c: pod clarification
Diffstat (limited to 'utf8.c')
-rw-r--r--utf8.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/utf8.c b/utf8.c
index e93c98aecf..0aede4c3a6 100644
--- a/utf8.c
+++ b/utf8.c
@@ -549,7 +549,8 @@ UTF8_CHECK_ONLY is also specified.)
Very large code points (above 0x7FFF_FFFF) are considered more problematic than
the others that are above the Unicode legal maximum. There are several
-reasons, one of which is that the original UTF-8 specification never went above
+reasons: they do not fit into a 32-bit word, are not representable on EBCDIC
+platforms, and the original UTF-8 specification never went above
this number (the current 0x10FFF limit was imposed later). The UTF-8 encoding
on ASCII platforms for these large code points begins with a byte containing
0xFE or 0xFF. The UTF8_DISALLOW_FE_FF flag will cause them to be treated as