Re: [BUG] with non-ascii characters in dir names
Martin Buchholz <martin(a)xemacs.org> writes:
Come on guys. Most uses of XSTRING_DATA in the source code are
entirely OK.
Unfortunately just 'most'. What bothers me most is that this one
occured in a file that has been marked as MULE-lized (and some of the
other suspect ones like this[1].
console-stream.c:75: fopen ((char *) XSTRING_DATA (tty), "r+");
should decide to work in a non-English locale, create files and
directories with non-ASCII characters in them, and make sure they work
with find-file, dired, start-process, etc. etc...
So the current breakage, probably introduced by the Windows port,
should be relatively easy to fix. A developer that decides to do this
As far as I can see this particular one was also in 20.4 and predates
the windows port. Likewise you probably never used open-database with
a non-ascii name.
Really wouldn't it be bettter just to rename XSTRING_DATA to
XSTRING_DATA_INTCODING such that
1. Future C writers get warned that this gives strings in XEmacs
internal incoding.
2. We never forget to check the current ones.
I am not advocating doing this now but I have the feeling this should
be done sometime and that why this particular number of XSTRING_DATA's
look scary.
Jan
[1] Yeah, I know ttys are unlikely to contain non-ascii names and we
are saved by our internal incoding. But it is wrong anyway. Sometime
in the future somebody is going to want to have /dev/dfü instead of
/dev/modem etc..
Jan> I am wondering. Suppose we were to redefine XSTRING_DATA such that it
Jan> always used 'raw-text' or maybe even 'binary' as the coding
Jan> system would that help?
Hey, XSTRING_DATA always accesses the contents of a string lisp
object, which must always be in the XEmacs internal encoding. The C
code is responsible for ensuring that random character strings from
the external world are not used to create lisp strings without proper
data conversion. In particular, build_string("foo") is only (barely)
OK because the internal encoding is a superset of ASCII, as are most
of the external encodings. Put one of your favorite European
characters into that string, and you've got yourself a core dump.
Martin
--
Jan Vroonhof http://www.math.ethz.ch/~vroonhof/
Mathematik, vroonhof ＠ math.ethz.ch
HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154
Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085