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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 03 Jan 2025 14:35:26 +0000
> From: michal@0lock.xyz
> Cc: 75207@debbugs.gnu.org
> 
> I've just built Emacs on somewhat new revision (577714e3fe) and cannot repro it there.
> Tag emacs-29.1 does not build by default on Windows so I didn't check.
> 
> My theory is that maybe the codepage of the machine Emacs was built on influences this??

Yes, it does, according to my reading of the code.  When we went from
unexec to pdumper builds, we introduced a bug whereby the relevant
variables are assigned values that come from the dump stage, and not
reinitialized after that.  If Emacs was dumped when the system
codepage was different, you will see problems when the dumped Emacs
starts with a different codepage, AFAICT.  As I said, this is not
limited to UTF-8, so it is good we found this problem.

> Or this has just been fixed on the latest version.

No, I don't think so.  I see the problem on the latest master branch.

> I debugged a bit and it looks like w32_ansi_code_page is set to 1252 at some point.

AFAICT, that happens when we load the pdumper file.

> M-: w32-multibyte-code-page -> 0
> M-: locale-coding-system -> cp65001
> M-: file-name-coding-system -> nil
> M-: default-file-name-coding-system -> cp65001

OK, I think this confirms my hypothesis.  I'll try to come up with a
patch, probably tomorrow.

> > We think that PATH is encoded in Windows-1252 codepage, and the question
> > is why and where do we err.  The above additional values I ask about might
> > help answer that question.
> 
> I can say for sure that it is not

When I say "we think", I mean Emacs thinks that, mistakenly.

> > If I send you a C-level patch, are you able to build Emacs after patching it,
> > preferably the master branch of our Git repository?
> 
> Sure.

OK, but you'll need to build Emacs with a different system codepage to
see the effects of the fix.