Re: [BUG] with non-ascii characters in dir names

Jan> Didier Verna <verna(a)inf.enst.fr&gt; writes: Jan> Note that the same Jan> change as needed to fix your bug needs to apply to the the NT Jan> version was well. Note that top that file claims the function has been Jan> MULE-ized. Jan> Probably. MULE is totally broken this regard. I looked at a few of Jan> them and most of them indeed look bogus. Jan> bolzano:vroonhof/cvs/xemacs-20/src> grep XSTRING_DATA *.c | wc -l Jan> 424 Jan> :-( Come on guys. Most uses of XSTRING_DATA in the source code are entirely OK. Back when I had a Japanese development enviromnent, I made sure I could use files and directories with Japanese file names. So the current breakage, probably introduced by the Windows port, should be relatively easy to fix. A developer that decides to do this 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... 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