Hi, Ingo Schwarze wrote on Sun, Jan 10, 2016 at 10:22:28PM +0100: > Todd C. Miller wrote on Sun, Jan 10, 2016 at 12:33:07PM -0700: >> On Sun, 10 Jan 2016 19:55:53 +0100, Ingo Schwarze wrote: >>> So, my conclusion is that it's the C standard that is carelessly >>> worded, not POSIX. I don't think the C standard intends to say >>> that fgetwc(3) and fputwc(3) are not allowed to set the error >>> indicator on an encoding error, it just doesn't clearly say that >>> they are required to. POSIX then adds the additional requirement, >>> merely failing to make it clear that it's resolving a careless >>> wording in the C standard.
>> POSIX marks its extensions to ISO C, but this behavior is not >> documented as an extension. I suggest you contant the Austin group >> for clarification. > Done: > > http://austingroupbugs.net/view.php?id=1022 > > Let's wait for feedback, then take that into consideration for our > decision. So, here is the result. The only answer that can be taken seriously is from Geoff Clare (of the Open Group). He says this: Geoff Clare wrote: > Ingo Schwarze wrote: :: ---------------------------------------------------------------------- :: (0003030) schwarze (reporter) - 2016-01-22 02:02 :: http://austingroupbugs.net/view.php?id=1022#c3030 :: ---------------------------------------------------------------------- :: Re: 0003027 :: :: Thanks for your feedback, geoffclare. To make really sure that i :: understand correctly what you are saying: Your intention is that POSIX :: should not be changed, that all the operating systems i listed should :: continue what they are already doing, and that the C standard should be :: amended to also require setting the error flag in case of an encoding :: error. Right? : I imagine that's what we would propose to the C commitee. Whether : they accept our recommendation is another matter. In conclusion, i would consider it a very bad idea to change all the operating systems to not set the error indicator, violating POSIX and making correct coding harder, just to please the not very nice C standard, then possibly change them all a second time once the C standard gets fixed. Consequently, i propose to not revert our fgetwc(3) patch and to commit this fputwc(3) patch, too, making us agree with FreeBSD, NetBSD, Dragonfly, SunOS, glibc, and POSIX, even tough nominally violating the C standard (but in a way that seems less dangerous than the inverse violation of POSIX). By the way, i'm running with this ever since and didn't notice any adverse effects. OK? Ingo Index: fputwc.c =================================================================== RCS file: /cvs/src/lib/libc/stdio/fputwc.c,v retrieving revision 1.6 diff -u -p -r1.6 fputwc.c --- fputwc.c 1 Oct 2015 02:32:07 -0000 1.6 +++ fputwc.c 23 Jan 2016 20:00:59 -0000 @@ -62,7 +62,7 @@ __fputwc_unlock(wchar_t wc, FILE *fp) size = wcrtomb(buf, wc, st); if (size == (size_t)-1) { - errno = EILSEQ; + fp->_flags |= __SERR; return WEOF; }
