|
|
Message-ID: <20170831182815.GA7054@brightrain.aerifal.cx>
Date: Thu, 31 Aug 2017 14:28:15 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Issues in mbsnrtowcs and wcsnrtombs
On Tue, Jul 18, 2017 at 11:05:29PM +0300, Mikhail Kremnyov wrote:
> Hi,
>
> It looks like there are some bugs in the implementations of mbsnrtowcs
> and wcsnrtombs.
> E.g. inside mbsnrtowcs there is this code:
>
> while ( s && wn && ( (n2=n/4)>=wn || n2>32 ) ) {
> if (n2>=wn) n2=wn;
> n -= n2;
> l = mbsrtowcs(ws, &s, n2, st);
>
> Here "n" is the number of source bytes to convert and "n2" is the number
> of wide chars that may be put to the destination, so it's incorrect to
> subtract one from another. And indeed a simple test shows that the
> function doesn't work correctly if long enough non-ascii string is
> passed to it. E.g.:
Failure to understand what you mean here kept me from making sense of
the problem right away, but I think I understand now. While derived
from a number of bytes (n), n2 is a bound on the number of output wide
characters to ensure that no more than 4*n2 (<=n) bytes of input may
be read. It will only be equal to the number of bytes of input read in
the case where each wide character was converted from a single byte
(i.e. ASCII input), and thus adjusting the remaining n by subtracting
n2 is incorrect. Instead, as your follow-up patch does, the number of
input bytes processed must be measured by taking the difference of old
and new values of s.
As long as I don't see any problems I'll go ahead and apply now.
Thanks and sorry for the delay getting back to this.
Rich
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.