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
