From zefram@fysh.org

A decode-then-encode cycle through the utf8-c8 encoding is meant to
round-trip an octet string. But if the input is the UTF-8 encoding
of a string that's not NFC normalised, the output ends up different,
because this normalisation got performed somewhere in the middle​:

Blob[uint8].new(101, 204, 129).decode("utf8-c8").encode("utf8-c8").perl
Blob[uint8].new(195,169)
Blob[uint8].new(195, 169).decode("utf8-c8").encode("utf8-c8").perl
Blob[uint8].new(195,169)

This is of particular concern for things like access to command-line
arguments​:

$ perl6 -e 'say @​*ARGS[0].encode("utf8-c8")' $'e\xcc\x81'
Blob[uint8]​:0x<c3 a9>
$ perl6 -e 'say @​*ARGS[0].encode("utf8-c8")' $'\xc3\xa9'
Blob[uint8]​:0x<c3 a9>

-zefram

From zefram@fysh.org

This problem no longer occurs.

-zefram

From @dogbert17

On Sun, 26 Feb 2017 23​:01​:18 -0800, zefram@​fysh.org wrote​:

This problem no longer occurs.

-zefram

Fixed with commit (2017-01-02) rakudo/rakudo@7c8b705

The RT System itself - Status changed from 'new' to 'open'

From @dogbert17

On Wed, 14 Mar 2018 13​:28​:05 -0700, jan-olof.hendig@​bredband.net wrote​:

On Sun, 26 Feb 2017 23​:01​:18 -0800, zefram@​fysh.org wrote​:

This problem no longer occurs.

-zefram

Fixed with commit (2017-01-02)
rakudo/rakudo@7c8b705

Test added with commit Raku/roast@d0d4609

@dogbert17 - Status changed from 'open' to 'resolved'