[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171120192850.GJ1627@brightrain.aerifal.cx>
Date: Mon, 20 Nov 2017 14:28:50 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Further wide stdio issues [Was: Re: [PATCH] fix fgetwc
when decoding a character that crosses buffer boundary]
On Sun, Nov 19, 2017 at 08:48:53PM -0500, Rich Felker wrote:
> On Sat, Nov 18, 2017 at 05:51:48PM +0100, Szabolcs Nagy wrote:
> > Update the buffer position according to the bytes consumed into st when
> > decoding an incomplete character at the end of the buffer.
>
> Further related problems:
>
> 1. fgetws is unable to accurately determine whether fgetwc failed due
> to hitting EOF on a clean stream vs hitting EOF in the middle of a
> truncated character. The latter is an EILSEQ condition and should
> cause fgetws to return a null pointer rather than a line not ending
> in newline.
>
> 2. fgetwc attempts to leave all but the first byte unread on EILSEQ so
> that calling fgetwc again will resync, but doesn't do this
> consistently when it has to call getc_unlocked to get new bytes
> rather than reading from the buffer.
>
> I think (1) can be fixed in an ugly way by setting errno to something
> other than EILSEQ before calling fgetwc, then checking if EILSEQ upon
> failure.
Patching this; here's a test case (attached).
Rich
View attachment "fgetws.c" of type "text/plain" (320 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
