> From: Bruno Haible <br...@clisp.org> > Date: Sun, 30 Apr 2017 17:27:50 +0200 > > > One scenario where this gets in the way is when the application > > includes some other header, e.g. ctype.h, which declares the same isw* > > functions as wchar.h and wctype.h -- if the inclusion of ctype.h is > > _after_ wchar.h/wctype.h are included, this produces compilation > > errors, because the prototypes of the isw* functions were first seen > > with the original wint_t type, and now are seen with the wider wint_t. > > We know how to fix such situations in gnulib. Thanks for the report.
I'm asking why get into such situations in the first place. What do we gain? As for fixing, the fixes are usually fragile and tend to break whenever the system headers are rearranged, for whatever reasons. Problems that stem from the order of including header files are always like that, and IME it's best to avoid them in the first place. > > Another scenario is when wint_t variables are passed to functions that > > expect pointers to WCHAR data type used by the lower-level Win32 APIs > > (LPCWSTR etc.) -- with the overridden type, this causes compilation > > warnings or errors, and requires casts or intermediate variables. > > Can you elaborate on these, please? WCHAR = wchar_t != win_t. Not sure what you want me to elaborate on. With the native data types, I can freely assign wint_t to wchar_t and vice versa; with the overridden Gnulib type, I cannot.
