While working on the pack part of the patch I'm running the following in
pp_pack.c:
code:
PP(pp_pack)
{
...
register SV *cat = TARG;
...
When I now check cat, I see that SvUTF8 is already on for it
In fact, it turns out to be:
SV = PVMG(0x818fee8) at 0x8249be0
REFCNT = 1
FLAGS = (PADTMP,SMG,POK,pPOK,UTF8)
IV = 0
NV = 0
PV = 0x82644c8 "perl"\0 [UTF8 "perl"]
CUR = 4
LEN = 5
MAGIC = 0x8264840
MG_VIRTUAL = &PL_vtbl_utf8
MG_TYPE = PERL_MAGIC_utf8(w)
MG_LEN = 4
The
sv_setpvn(cat, "", 0);
a bit later clears the string, but the utf8-ness and magic hangs around.
Is this normal ?
If this is normal, isn't this then a bug in pack() ?
For it seems the output string can have the utf8 flag even if you never
asked for that:(changing the meaning, this is not an upgrade but a rude
setting of the flag)
perl -wle 'for ("N", "U0N", "N") { print utf8::is_utf8(pack($_, 1)) ? "utf8" :
"bytes" }'
bytes
utf8
utf8
I think the last line should have been "bytes" again.
Am I always supposed to clean up that kind of unwanted state if I
get an sv from a TARG ?
Shouldn't perl itself take care of that before presenting a TARG ?
If not so, what's the way you're supposed to get a "clean slate" before
starting to use the value ?
Is maybe perl riddled with variations of this bug ?
