> From: Gavin Smith <[email protected]> > Date: Fri, 30 Jan 2026 20:18:58 +0000 > Cc: Bruno Haible <[email protected]>, [email protected], [email protected], > [email protected] > > I'm reviewing remaining issues to be worked on before the next Texinfo > pretest. Has there been any progress on these issues?
Some progress, see below. > I saw that there was a patch to fix the stdio-consolesafe.c issue: > https://lists.gnu.org/archive/html/bug-gnulib/2026-01/msg00205.html. > > I saw some emails between you and Bruno on bug-gnulib, but no final > resolution of the wchar.h/wctype.h issue: > https://lists.gnu.org/archive/html/bug-gnulib/2026-01/msg00210.html That's right. Bruno asked me to provide some information from the MinGW headers I use, and I did. I guess Bruno is considering some solutions. He also indicated that he had health problems, so maybe this explains why he didn't respond until now. > As Eli's patch showed, it appears to be unnecessary on the MinGW > system he is using to include wchar.h in the Gnulib wchar.h. You mean, include wchar.h in the Gnulib wctype.h, right? > The first include is guarded by HAVE_WINT_T: > > #if @HAVE_WINT_T@ > /* Solaris 2.5 has a bug: <wchar.h> must be included before <wctype.h>. */ > # include <wchar.h> > #endif > > Perhaps there is another condition that could be used instead that would > be limited to the Solaris 2.5 situation? Yes, if only Solaris needs this. > As for the second, the comment says it is for the sake of MinGW, so > it is odd that it should break the build on MinGW: I think the reference is to MinGW64, not the older flavor I'm using. > /* Native Windows (mingw, MSVC) have declarations of towupper, towlower, and > isw* functions in <ctype.h>, <wchar.h> as well as in <wctype.h>. Include > <ctype.h>, <wchar.h> in advance to avoid rpl_ prefix being added to the > declarations. */ > #if defined _WIN32 && ! defined __CYGWIN__ > # include <ctype.h> > # include <wchar.h> > #endif > > Perhaps Eli could advise if the problem this is supposed to solve exists > on the version of MinGW he is using? Could there be some way to distinguish > between "old" MinGW and "new" MinGW? The same problem does exist here, because it is due to MSVC legacy. But in the case of "old" MinGW, when Gnulib's wctype.h is included from MinGW wchar.h, _WCHAR_H guard is already defined (by MinGW wchar.h which included wctype.h), so including wchar.h again is unnecessary. So perhaps modifying the above conditional to say #if defined _WIN32 && ! defined __CYGWIN__ && ! defined _WCHAR_H is all that's needed? The "new" MinGW doesn't include wctype.h from its wchar.h, so that problem is not supposed to exist there, and _WCHAR_H will not be defined at this point (the "new" MinGW uses _INC_WCHAR as the guard for wchar.h header file, so even if its wchar.h is included earlier, _WCHAR_H will still be undefined). > Eli wrote: > > I see only one: _WCHAR_H. But it's the idempotency guard of wchar.h, > > and will be defined once wchar.h was included for the first time, so > > I'm not sure it's what you want. > > If I understand correctly, the idea is to check if we are being included > from wchar.h. Hence the _WCHAR_H would suffice, as long as it was defined > before the include. (If it was defined right at the end of the file, it > wouldn't work.) Yes, see above. > If that doesn't work, another possibility to use symbols in a file included > by wchar.h before it included wctype.h (if there are any). We could use __MINGW32_VERSION, which is only defined by the "old" MinGW. > Another idea is, that since the problem comes about when including from > system wchar.h, that is included from Gnulib wchar.h, some symbol could > be defined in Gnulib wchar.h before including <ctype.h>. The Gnulib > include guard symbol _GL_WCTYPE_H isn't defined until after wchar.h is > included but there could be another one. This won't work, because Gnulib wchar.h does NOT include wctype.h.
