bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Overriding the MS-Windows wint_t type considered harmful


From: Eli Zaretskii
Subject: Overriding the MS-Windows wint_t type considered harmful
Date: Sun, 30 Apr 2017 18:20:57 +0300

Two Gnulib header files, wctype.h and wchar.h, override the wint_t
data type as defined in the MS-Windows header files, like this:

  /* mingw and MSVC define wint_t as 'unsigned short' in <crtdefs.h> or
     <stddef.h>.  This is too small: ISO C 99 section 7.24.1.(2) says that
     wint_t must be "unchanged by default argument promotions".  Override it.  
*/
  # if @GNULIB_OVERRIDES_WINT_T@
  #  if !GNULIB_defined_wint_t
  #   if @HAVE_CRTDEFS_H@
  #    include <crtdefs.h>
  #   else
  #    include <stddef.h>
  #   endif
  typedef unsigned int rpl_wint_t;
  #   undef wint_t
  #   define wint_t rpl_wint_t
  #   define GNULIB_defined_wint_t 1
  #  endif
  # endif

IME, this causes more trouble than it solves.  While building a
pretest of Texinfo 4 with mingw.org's MinGW, it has bitten me twice.

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.

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.

More generally, I don't see how this overriding of a native type could
possibly be a good idea, when Gnulib doesn't replace library functions
which use this data type.

So I propose to stop overriding wint_t in native Windows builds, as it
generally means trouble.  I understand the rationale as expressed in
the comment above, but I think that in this case the cure is worse
than the decease.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]