Re: sed bug: ASCII NUL doesn't work on the rhs of y// commands

[Jim Meyering]

On Fri, Sep 5, 2014 at 10:41 PM, Jim Meyering <address@hidden> wrote:
> On Wed, Sep 3, 2014 at 4:19 AM, Paolo Bonzini <address@hidden> wrote:
>> Il 03/09/2014 03:09, address@hidden ha scritto:
>>> Hi,
>>>
>>> The subject pretty much says it all for this bug. Compare the output of
>>> "echo abc | sed -e 's/b/\x00/' | hexdump -c" and "echo abc | sed -e
>>> 'y/b/\x00/' | hexdump -c". The s command behaves correctly (as I would
>>> expect, it replaces the 'b' with a NUL character), while the y command
>>> fails to output anything when it should print NUL, resulting in an
>>> output file shorter than the input was.
>>
>> Looks like the bug was introduced when "y" was extended to support
>> multibyte characters.  The minimal patch should be to change
>>
>>          int trans_len = strlen(trans[2*i+1]);
>>
>> to
>>
>>          char *trans = trans[2*i+1];
>>          int trans_len = *trans == '\0' ? 1 : strlen(trans);
>>
>> in sed/execute.c
>
> Hi Paolo,
> Thanks for the suggestion.
> Here's a complete patch (can't reuse the name
> "trans" that way, and I prefer to s/int/size_t/).
> I expect to find the precise commit that introduced
> the bug, adjust the log and NEWS,
> and then push tomorrow.

I updated NEWS, but didn't take the time to find the precise commit.
I was surprised to see there is only one git tag.

I've also pushed the following to fix the trivial "version" test failure:

0001-maint-correct-failing-version-test.patch
Description: Binary data