Follow @Openwall on Twitter for new release announcements and other news
[<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.