Mercurial > hg > xemacs-beta

comparison src/lread.c @ 4096:1abf84db2c7f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[xemacs-hg @ 2007-08-04 20:00:10 by aidan] Preserve invalid UTF-8, UTF-16 sequences on encoding, decoding.
author aidan
date Sat, 04 Aug 2007 20:00:24 +0000
parents 3214dca89755
children 75d0292c1bff
comparison
equal deleted inserted replaced
4095:bff7e065cfdc 4096:1abf84db2c7f
1692 make_char (c)); 1692 make_char (c));
1693 break; 1693 break;
1694 } 1694 }
1695 } 1695 }
1696 1696
1697 if (i > 0x110000 || i < 0)
1698 {
1699 syntax_error ("Not a Unicode code point", make_int(i));
1700 }
1701
1697 lisp_char = Funicode_to_char(make_int(i), Qnil); 1702 lisp_char = Funicode_to_char(make_int(i), Qnil);
1698 1703
1699 if (EQ(Qnil, lisp_char)) 1704 if (EQ(Qnil, lisp_char))
1700 { 1705 {
1701 /* This is ugly and horrible and trashes the user's data, but 1706 /* Will happen on non-Mule. Silent corruption is what happens
1702 it's what unicode.c does. In the future, unicode-to-char 1707 elsewhere, and we used to do that to be consistent, but GNU error,
1703 should not return nil. */ 1708 so people writing portable code need to be able to handle that, and
1704 #ifdef MULE 1709 given a choice I prefer that behaviour.
1705 i = make_ichar (Vcharset_japanese_jisx0208, 34 + 128, 46 + 128); 1710
1706 #else 1711 An undesirable aspect to this error is that the code point is shown
1707 i = '~'; 1712 as a decimal integer, which is mostly unreadable. */
1708 #endif 1713 syntax_error ("Unsupported Unicode code point", make_int(i));
1709 return i; 1714 }
1710 } 1715
1711 else 1716 return XCHAR(lisp_char);
1712 {
1713 return XCHAR(lisp_char);
1714 }
1715 } 1717 }
1716 1718
1717 1719
1718 static Ichar 1720 static Ichar
1719 read_escape (Lisp_Object readcharfun) 1721 read_escape (Lisp_Object readcharfun)