Re: [BUG] with non-ascii characters in dir names
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
I haven't checked on it further but that one is bound to be
wrong.
These are also suspect
frame-x.c:1350: strcpy (dnd_data + dnd_len - 1, (CONST char *)XSTRING_DATA (XCAR
(run)));
frame-x.c:1365: dnd_data = (char *)XSTRING_DATA (data);
That's fairly new code written by Oliver Graf.
These ones are surely wrong:
fileio.c:1731: else if (stat ((CONST char *) XSTRING_DATA (newname), &out_st) <
0)
fileio.c:1734: ifd = interruptible_open ((char *) XSTRING_DATA (filename), O_RDONLY |
OPEN_BINARY, 0);
fileio.c:1773: ofd = open( (char *) XSTRING_DATA (newname),
No, you're surely wrong. :-) Seriously, stat(), open() and
interruptible_open() do so-called Mule-encapsulation, which means that
it is safe to call them with XSTRING_DATA.
That taken into account, I don't think things are nearly as bad as you
make them out to be. I could be wrong, though.
The one in Fopen_database is clearly wrong also. Also the database
keys are in XEmacs internal incoding. Was that intended?
The database code is un-Muleized, I think.
P.P.S. FSF Emacs makes of the lisp allocator to allocate the
strings. Therefore they do not need alloca. However it seems to
create a new buffer for each filename it needs to convert!
Gag.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth