[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