Re: Multibyte and unibyte file names

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> under what circumstances could such a primitive receive an encoded
>> file-name, if all the file names returned to Elisp (by things like
>> directory-files) are already decoded?
> One way is that a primitive gets called from C.

So we should fix the (C) caller.

> if we _want_ to support encoded file names, the code needs to DTRT
> with them, even if this happens only once in a blue moon.

I think the right thing to do with unibyte file names is to treat them
as a sequence of bytes, not a sequence of encoded chars.  If the caller
doesn't like it, then she should pass a decoded file name instead.

> I "worry" because they need separate code,

I think if we only support "sequences of bytes" (unibyte strings) and
"sequenced of decoded chars" (multibyte strings), there is not much need
for separating the code since there's no risk of a special char (like
"/", "." or ":") char appearing there while it meant something else.

> especially with multibyte encodings; writing that code for an encoding
> not supported by the current locale is tricky at best, if not
> downright impossible, and certainly inefficient.

Better not second guess the caller about which encoding she meant.

> Are you saying that since this happens
> infrequently, we could process such file names in a broken way,

Right.

> e.g. finding a directory separator where there's none, as demonstrated
> in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13515#5?

That seems like a real bug, tho:

   (let ((file-name-coding-system 'cp932))
     (expand-file-name "表" "C:/"))

should not return "c:/\225/".  Why does it even pay attention to
file-name-coding-system?


        Stefan