Hi Eli, > From: Eli Zaretskii [mailto:e...@gnu.org] > Sent: 2017年11月4日 16:53 > > What do you mean by "gnu printf related functions"? If this is a build that > doesn't define ENABLE_NLS, then wget outputs the original text using the MS > runtime versions of printf. And in a build that does define ENABLE_NLS, the > text is additionally processed by the GNU gettext library. So is the problem > with the build which defines ENABLE_NLS or the build that didn't define > ENABLE_NLS? Or is it with both?
I'm not sure whether you did any tests. And I can't tell what's the result with 'ENABLE_NLS', I don't have gnu gettext, resulting 'ENABLE_NLS' undefined. The logics I know of the code is that some 'logprintf' are used before 'log_int', and some are used after that. And the logic of how 'logprintf' works is as the attached screenshot 'log_vprintf_internal_logics' shows. A little different as you say. They don't work through the same printing function! The gnulib one needs setting codepage to multibyte codepage, if it is not for single byte, as I said before. (Maybe you can dig out why.) >> '_getmbcp' is used > Maybe the problem is that the codepage used for the console output is > different from the system's ANSI codepage? What does GetConsoleOutputCP > return in the case you describe? > > What happens if ENABLE_NLS is defined? Your patch only handles the > situation where ENABLE_NLS is NOT defined. Yes, my patch only handles the situation I meet with, by using necessary predefined conditions. I leave the others untouched, because I don't have the needed libraries. I hope others who has the environments can test it and turn on the switches when necessary. And I can tell you that 'GetConsoleOutputCP' returns the codepage as command 'chcp'. It is right. The gnu 'vsnprintf' doesn't work right with 'setlocale' omitted. Best Regards, YX Hao
