Then, doesn't it make sense to stick to the terminology that is used elsewhere (e.g. perlfunc "Note the characters: depending on the status of the socket, either (8-bit) bytes or characters are received."). With the logical extension that strings with (UTF8=0) are 'byte strings'. And strings with UTF8=1 are 'character strings'.

At the Perl level of course. At the C-level, they are all just byte arrays until you give them to something that attempts to interpret them differently.

Which would make this piece oxymoronology:

If sv contains the byte string "\x80\x81", the pointer returned by SvPVX(sv) points to one of the following:

• two bytes 80 81*
• three bytes 80 81 00
• four bytes C2 80 C2 81*
• five bytes C2 80 C2 81 00

Read as:

If sv contains the character string "\x80\x81", the pointer returned by SvPVX(sv) points to one of the following:

• two bytes 80 81*
• three bytes 80 81 00
• four bytes C2 80 C2 81*
• five bytes C2 80 C2 81 00

(You still haven't demonstrated how you can get those four to exist with only two string types)

But never mind, it doesn't matter, because had you been that clear, it would have then killed this thread stoney dead way back at level 5 when I said, I was only interested in dealing with "byte strings". Because it simply doesn't make sense to interleave (multi-byte) characters with constant bytes in order to pad them to 10-bit HDMI entities within 16-bit fields.

If you make up terminology, and ignore all my protestations that: I know what I'm doing; and I'm doing what I know to be right; stupid threads like this are the result.

I'd still like to see a good (realistic), use case for strings of variable width packed integers, but since they don't work, it doesn't really matter.

And this really is my last post in this thread.