Re: Overriding the MS-Windows wint_t type considered harmful

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden
> Date: Mon, 01 May 2017 02:50:25 +0200
> 
> 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.

Is this really a more important use case than the ones I had to deal
with during the last week?  (See bug-texinfo discussions for the
details.)

Let me turn the table, and ask you why didn't you provide a valid
inode values in your latest rework of fstat and stat for MS-Windows?
The comment was that the ino_t type is not wide enough to support
that.  IOW, providing a useful inode (and device) would have meant
overriding the native definition of 'struct stat', and you've decided
not to do that.  I understand the dilemma, and therefore have
sympathies to your decision, even though I myself took the other
alternatives a few times (see Emacs, for example).

But if such considerations are valid in the case of stat/fstat, where
we know that gobs of GNU software use the device and inode for
implementing important features and optimizations, then how come the
much less important use cases with semi-buggy WEOF processing are not
handled with the same caution?  Why override the native definition of
a type to cater to such unimportant use case, and risk breaking
applications which assume wint_t is what it is on Windows?  The
difference between these two decisions makes very little sense to me.

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

I propose to remove the reason that would require such management.  If
possible, that's a better engineering solution, won't you agree?

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

This is C we are talking about.  Code that uses data types of the same
size interchangeably is all over the place.  And coding for Windows,
trying to support applications that assume Posix, means standards mean
very little.  Doing that is hard as it is, as you well know, so it's
best not to make any harder than it has to be.

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

Thank you for mocking me.  I will in the future think twice before
posting to this list.