bug#26779: expr length

[Assaf Gordon]

Hello,

Attached an updated version of the 'expr/multibyte' patch.

> On May 9, 2017, at 08:31, Pádraig Brady <address@hidden> wrote:
> Definitely needs a NEWS entry
> and mention of this bug in the commit message.

I added two NEWS entries: one for the bug fix and one for the new multibyte 
support.

I could not find an exact version where this bug was 'introduced'.
'expr' never had a notion of multibyte strings, it was gnulib's "re_match"
which gained multibyte support.
The earliest gnulib mention of re_match and multibyte I could find is this:
  commit 42f97e3f0c576afb94226c8493f3567b44352ca8
  Author: Richard Stallman <address@hidden>
  Date:   Fri Apr 3 07:33:13 1998 +0000

> On May 10, 2017, at 21:24, Paul Eggert <address@hidden> wrote:
> 
> A couple of things. First, since performance doesn't matter here, wouldn't it 
> be simpler to convert to wide character form by using mbstowcs, do the work 
> in wide-character form, and then convert back via wcstombs? The resulting 
> code should be easier to maintain, I'd think.

The downside of 'mbstowcs' is that it fails and does not continue
when it encounters invalid multibyte sequences, whereas keeping
the string as 'char*' and using mbschr (with the additional code)
does handle invalid sequences fine (and the tests include such cases).

What do you think ?
I can work on a different patch with wide-char strings if this is deemed 
worthwhile.


> Also, please stick to GNU style for operator spacing and parenthesization.

I fixed the one case I spotted - if I missed any, please let me know
("make syntax-check" passes, but there could be others).

regards,
 - assaf

0001-expr-add-multibyte-support.patch.gz
Description: GNU Zip compressed data