zero-length string loses encoding in .pbc

[pmichaud]

A zero-length utf8 string loses its encoding when saved in a .pbc file:

pmichaud@orange:~/parrot/trunk$ ./parrot_config revision
48985
pmichaud@orange:~/parrot/trunk$ cat z.pir
.sub 'main' :main
    $S0 = utf8:unicode:""
    $I0 = encoding $S0
    $S1 = encodingname $I0
    say $S1
.end

pmichaud@orange:~/parrot/trunk$ ./parrot -o z.pbc z.pir
pmichaud@orange:~/parrot/trunk$ ./parrot z.pir
utf8
pmichaud@orange:~/parrot/trunk$ ./parrot z.pbc
ascii
pmichaud@orange:~/parrot/trunk$ 

This makes a difference for functions that make use of string encoding directly; for example, Rakudo passes C<utf8:unicode:""> to the C<get_string_as> method of ByteBuffer to request a unicode string (but is getting an ascii string when invoked from a .pbc).

Pm

[jkeenan]

Patrick, would you characterize this as a newly discovered bug, or as a regression from previously correct behavior?

[plobsing]

Replying to jkeenan:

Patrick, would you characterize this as a newly discovered bug, or as a regression from previously correct behavior?

This is a regression introduced in r48969. The CONST_STRING table is ascii-only.

Not sure if we want to revert or ammend.

[jkeenan]

Possibly related ticket: TT #468

[jkeenan]

cc-ing chromatic, as r48969 was his.

[pmichaud]

Replying to jkeenan:

Patrick, would you characterize this as a newly discovered bug, or as a regression from previously correct behavior?

It's definitely a regression -- it worked correctly in previous versions of Parrot. I noticed it today because one of Rakudo's spectests started failing when running against recent Parrot revisions. I didn't have time to search the Parrot history to find the offending commit, but I'm reasonably certain plobsing++ is correct in its identification.

Pm

[bacek]

r48969

-- Bacek

[plobsing]

Added todo'd testcase in r48987.

[bacek]

Fixed in r48992.