[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file na

From: Eli Zaretskii
Subject: Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file names
Date: Wed, 01 Jul 2015 18:47:55 +0300

> Date: Wed, 01 Jul 2015 10:14:20 -0400
> From: Ken Brown <address@hidden>
> Cc: address@hidden
> I've tested this a little with file names containing UTF-8-encoded 
> Chinese and other non-ASCII characters, and it appears to work OK.  But 
> I *think* it only works because of accidental implementation details of 
> cygwin-convert-file-name-from-windows (and the underlying Cygwin 
> function cygwin_conv_path).  Basically, it seems that these functions 
> don't actually try to do any conversion if they are given a multibyte 
> string instead of the expected UTF-16 string.

That was also my conclusion.

> So even though this change *might* be harmless, I think it could lead to 
> bugs later if implementations change.  I don't think 
> cygwin-convert-file-name-from-windows should be called on a file name 
> that is not known to be a (UTF-16-encoded) Windows file name.

The UTF-16 encoding is not an issue, because
cygwin-convert-file-name-from-windows calls to_unicode to ensure that.

I think this code needs to look at the result of expand-file-name for
the file and the default directory in effect, and check whether the
result begins with a drive letter.  If it does, it should call

reply via email to

[Prev in Thread] Current Thread [Next in Thread]