GNU bug report logs - #75207
29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8

Previous Next

Full log

View this message in rfc822 format

From: Michał Lach <michal <at> 0lock.xyz>
To: 75207 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#75207: Fwd: bug#75207: 29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8
Date: Fri, 03 Jan 2025 11:49:34 +0000

Forgot to CC the bug report mail.

> Begin forwarded message:
> 
> From: <michal <at> 0lock.xyz>
> Subject: RE: bug#75207: 29.4; Path conversion from native codepage to UTF-8 fails when Windows is set by default to UTF-8
> Date: 3 January 2025 at 02:48:53 CET
> To: "'Eli Zaretskii'" <eliz <at> gnu.org>
> Reply-To: <michal <at> 0lock.xyz>
> 
> M-: (getenv "ENU") -> nil
> M-: current-locale-environment -> "ENG"
> M-: w32-ansi-code-page -> 65001
> M-: (default-value 'buffer-file-coding-system) -> iso-latin-1-dos
> 
>> That said, presenting a clear recipe could help us gradually improve 
>> support for
>> this, as Windows improves its part in parallel.
> 
> Here is the repro.
> 1. Put a path to your "PATH" environmental variable with some diacritic 
> character (ł in my case, maybe it won't work for some)
> 2. M-: exec-path returns gibberish
> 
> Here, "Michał" becomes "MichaÅ‚", you can get a similar result if you do 
> MultiByteToWideChar using Windows-1252 codepage on a UTF-8 path.
> 
> I've digged around and it looks like codepage_for_filenames (src/w32.c) at 
> somepoint returns the Windows-1252 codepage.
> This is then passed to MultiByteToWideChar() and the scenario that I 
> described above happens.
> I've checked this hypothesis with API Monitor and this is what actually 
> happens, I can attach a trace if you will find it useful.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.