bug-gnulib
[Top][All Lists]
Advanced

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

Re: Overriding the MS-Windows wint_t type considered harmful


From: Bruno Haible
Subject: Re: Overriding the MS-Windows wint_t type considered harmful
Date: Mon, 01 May 2017 02:50:25 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-75-generic; KDE/5.18.0; x86_64; ; )

Eli Zaretskii wrote:
> I'm asking why get into such situations in the first place.  What do
> we gain?

In general, by using gnulib, you gain higher compliance to the POSIX
and C standard. In other words, code that was written with these standards
in mind has higher chances of working correctly with gnulib than without.

In the particular case of 'wint_t': The problem is no such much that
  wint_t = 'unsigned short'
is not unchanged by argument promotions, but rather that this type
is not larger than 'wchar_t'. This piece of code

  wint_t c = getwchar();
  if (c == WEOF) goto eof_handling;

is only correct when wint_t is larger than wchar_t. The original
definition of WEOF is (wint_t)0xFFFF. This is an unassigned Unicode
character, but it can occur in files. You must not misinterpret it
as being the end of the file or stream.

It's like 20 years ago, when people were writing

  char c = getchar();
  if (c == EOF) goto eof_handling;

and were wondering why this was buggy.

> As for fixing, the fixes are usually fragile and tend to break
> whenever the system headers are rearranged, for whatever reasons.

This is manageable.

> > > 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.

You CAN freely assign wint_t to wchar_t and vice versa: they are integer
types. What you cannot assign freely is a wint_t* to a wchar_t* or vice
versa. Which means that you discovered a bug in the source code of your
package. There is NO STANDARD that would state that wint_t and wchar_t
are of the same size.

""I have to port code that makes invalid assumptions. Gnulib detects that
  this code makes invalid assumptions. Let me complain about Gnulib.""

Bruno




reply via email to

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