With use bytes turned off:
SV = PV(0x1c71c9e8) at 0x1c202710 REFCNT = 1 FLAGS = (PADMY,POK,pPOK,UTF8) PV = 0x1cab9940 "\0\0\3\302\261---\nCONTENT_LENGTH: [etc]
With use bytes turned on:
SV = PV(0xbfdd1e8) at 0xb734730 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0xbfeb710 "\0\0\3\261---\nCONTENT_LENGTH: [etc]
With use bytes turned off and with calling utf8::downgrade on the string before dumping:
SV = PV(0xd5ed9e8) at 0xd0d3710 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0xd98b100 "\0\0\3\261---\nCONTENT_LENGTH: [etc]
Calls to Encode::is_utf8 are also tracking those values as noted by the dump.
aHA.
Resorted to reading the code in pp_pack.c, discovered that the UTFness of a packed string appears to be based on the UTFness of its components (which makes sense). The second string I'm packing here came from the Net::Async::FastCGI::Request stdin data, and was UTF8-flagged. So the question turns into how to convince that module to forget about encodings in its I/O - the code I'm building here is just relaying bits from one place to another and shouldn't be touching them.
In reply to Re^2: use bytes vs packed data
by RDOlson
in thread use bytes vs packed data
by RDOlson
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |