bug#13515: 24.3.50; file-name operating functions are broken on Japanese Windows

[Kazuhiro Ito <kzhr@d1.dion.ne.jp>]

> > By the fix for Bug#12933, dostounix_filename could receive such
> > string.
> 
> Before that fix, dostounix_filename would indeed accept such file
> names, but what it did with them was exhibiting undefined behavior,
> because it treated multibyte strings in Emacs internal representation
> as if they were simple unibyte strings.

Agreed.  On Japanese Windows, Emacs had been able to treat file name
strings correctly in many years accidentally.

 > > In addition, that change also let the below code fail.
 > > 
 > > (let ((file-name-coding-system 'cp1252))
 > >   (expand-file-name "漢字" "C:/"))
 > > 
 > > -> "c:/  "
 > 
 > IMO, this snippet doesn't make sense and cannot be supported.
 > expand-file-name calls a number of system APIs which need the file
 > name be encoded, so using file-name-coding-system that cannot possibly
 > encode a file name is not supposed to work.
 > 
 > Do you have a real-life situation where such cases emerge and need to
 > be supported?

 None for me, sorry for inappropriate example.  But the docstring of
 w32-downcase-file-names says it affects remote file names and the fix
 for Bug#12933 also affects other functions without using system APIs
 (e.g., file-name-directory).  I guess it would be better that these
 functions (except ones using system APIs) didn't depend on codepage.
 Does Emacs neither support the below code?

 (let ((file-name-coding-system 'cp1252))
   (file-name-directory "漢字/"))

-> "  /"

-- 
Kazuhiro Ito