Multibyte conversion bugs and fixes

Marc Lehmann schmorp at schmorp.de
Sat Apr 26 05:06:29 CEST 2008


On Sat, Apr 26, 2008 at 10:34:10AM +0900, Neil Booth <neil at daikokuya.co.uk> wrote:
> Hi!  Thanks for rxvt-unicode.

Thanks for digging out this issue :) One minor nitpick, however:

> @@ -2380,13 +2380,19 @@ rxvt_term::next_char () NOTHROW
>  
>        if (len == (size_t)-2)
>          {
> +	  // Reset to initial conversion state from undefined
> +	  mbrtowc (0, 0, 0, mbstate);

This would introduce a bug (it would eat characters at the end of the
buffer). Are you sure netbsd requires this? If yes, then netbsd is buggy.

>        if (len == (size_t)-1)
> +	{
> +	  // Reset to initial conversion state from undefined
> +	  mbrtowc (0, 0, 0, mbstate);

well spotted, this is a real bug! thanks for tracking it down.

(gnu/linux manpages are abysmally bad)

>        if (l < 0)
> +      {
> +	// Reset to initial conversion state from undefined
> +	wcrtomb (0, 0, mbs);


this is a bug, too!

however, should not, in theory, in this case, the buffer returned by
wcrtomb added to the string (wcrtomb returns a reste shift state sequence
in this case)?

although, after na illegal sequence was encountered, it doesn't really
matter in what state the conversion really is.

Both fixes are applied and will be part of the next release, which will
include a fix for the select backend used on netbsd as well... :)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\




More information about the rxvt-unicode mailing list