Hi Lasse, > The first version of the patch had bad bugs. I apologize if those bugs > gave you the above impression.
I didn't notice bugs in details of the first version of your patch. In the first time, I focused my thinking on the big picture. > > Therefore my request to do this change of conversion on *all* file > > system APIs, or on none. > > Understood. At least the stat module could be fixed to give it long > name support. Other modules could be verified for long name support > too. Perhaps EOVERFLOW handling is also worth checking. This is too much > for me in the foreseeable future, so if it means that the current patch > isn't usable alone, then that's how it is. I'm not inclined to work on the missing parts either: as said in the previous mail, the current way of doing file name mapping (wchar_t[] -> char[]) in Windows is established for 30 years. Maybe we should spread the word about the UTF-8 mode, that you made us aware of recently [1]. In this mode, the conversion is 1:1 (except for file names with lone surrogates, which are arguably invalid anyway). I would guess that as even Microsoft programs move away (*) from the "ANSI codepage" to UTF-8, the user expectation regarding the encoding of files created by programs will move to UTF-8. (*) Microsoft Visual Studio Code already assumes UTF-8 by default since 2016. [2] Bruno [1] https://lists.gnu.org/archive/html/bug-gnulib/2024-12/msg00159.html [2] https://stackoverflow.com/questions/38528384/
