mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Issues in mbsnrtowcs and wcsnrtombs
Date: Thu, 31 Aug 2017 14:28:15 -0400	[thread overview]
Message-ID: <20170831182815.GA7054@brightrain.aerifal.cx> (raw)
In-Reply-To: <c23a73f5-34b4-99e8-786f-622ae42d41e8@gmail.com>

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


      parent reply	other threads:[~2017-08-31 18:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18 20:05 Mikhail Kremnyov
2017-08-09 17:57 ` Mikhail Kremnyov
2017-08-12  0:31   ` Rich Felker
2017-08-31 18:28 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170831182815.GA7054@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).