Re: Overriding the MS-Windows wint_t type considered harmful

[Bruno Haible]

Hi Eli,

> >   wint_t c = getwchar();
> >   if (c == WEOF) goto eof_handling;
> 
> 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.)

There is no "more important use case". Scanning
  https://lists.gnu.org/archive/html/bug-texinfo/2017-04/
  http://svn.savannah.gnu.org/viewvc/*checkout*/texinfo/trunk/ChangeLog
  
http://svn.savannah.gnu.org/viewvc/texinfo/trunk/tp/Texinfo/MiscXS/misc.c?r1=7762&r2=7765
  
http://svn.savannah.gnu.org/viewvc/texinfo/trunk/tp/Texinfo/Convert/XSParagraph/xspara.c?r1=7651&r2=7765
I can only see 3 issues, 2 of them we already discussed:

  1) The <wchar.h> problem, which you already reported in
     https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00166.html
     - thank you for this report.

  2) The previous code was defining iswspace and iswupper functions.
     Defining symbols with the same name as system function (at the linker
     level) is dangerous practice on all non-ELF systems (Mac OS X,
     AIX, Cygwin, Windows) anyway. And yes, this problem got worse
     through Gnulib's type redefinition.

  3) The previous code assumed that a wint_t* is the same as a WCHAR*.
     Not guaranteed by any standard nor Microsoft documentation.

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

Yes, I agree with that, and it is in fact part of the next steps, that
I mentioned yesterday in
  https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00159.html

But since overriding 'struct stat' can cause problems (e.g. some code
may assume that stat is _stati64) and not every program needs this,
I plan to make provide this support through a transversal module
https://lists.gnu.org/archive/html/bug-gnulib/2017-04/msg00117.html -
so that packages can choose whether they want it or not.

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

It happens that simpler features often get implement earlier than more
complex ones. Overriding wint_t is simpler than writing new stat, fstat
implementations.

Bruno