I never said or implied that the types are equivalent.

No. You suggested that assigning from one type to another doesn't change the meaning of the value contained. Except, it often does.

The rest is just another diversionary tactic from the subject from the discussion:

Using SvPVX() will NEVER cause it to silently encode your bytes using UTF-8.

No. You suggested that assigning from one type to another doesn't change the meaning of the value contained. Except, it often does

An overflow isn't a change in meaning, it's a change in value. The closest you'd have to a change in meaning is a struct pointer cast, and that's just not relevant here.

I don't why you keep repeating in giant bold letters something I have agreed with. It doesn't actually do the encoding, but it's the only way you'll get the encoded version implicitly. I was talking about the effect of SvPVX, not the implementation of SvPVX. Note that I write my posts for general readership.

Update: Added second paragraph.

Sorry, but I'm still gonna disagree with you.

An overflow isn't a change in meaning, it's a change in value.

No. The value (bitpattern) hasn't changed one iota. Only the meaning assigned to that value:

#! perl -slw
use 5.010;
use strict;
use Inline C => Config => BUILD_NOISY => 1;
use Inline C => <<'END_C',  NAME => '_junk', CLEAN_AFTER_BUILD => 0;

void doit( SV *dummy ) {
    int i = -1;
    unsigned int j = i;

    printf( "i: %d : %4x\n", i, i );
    printf( "j: %u : %4x\n", j, j );
}
END_C

doit( 1 );
__END__
C:\test>junk
...
i: -1 : ffffffff
j: 4294967295 : ffffffff
[download]

And there is no "overflow" involved, as the full build log below dmonstrates. No warnings. Which makes it the perfect analogy for two identical strings of bytes, with differing setting of the SVf_UTF8 flag. Same value, different meaning. To Perl.

something I have agreed with.

Where? I've looked at the whole thread again and this:

It doesn't actually do the encoding,.

is the first time I can see.

but it's the only way you'll get the encoded version implicitly.

I've been pointing out right from the very beginning, that I'm not interested in getting "the encoded version", because there will never be an encoded version. Because I'm never going to call encode() on binary data that can never be safely or logically treated as any form of unicode.

<Reveal this spoiler or all in this thread>

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"I'd rather go naked than blow up my ass"

And now to your belated and unannounced update.

you haven't ruled out doing something like $pascal_bytes = chr(length($bytes)) . $bytes;. For long enough strings, it upgrades without calling upgrade and without Perl assigning any meaning to the string.

That is wrong in so many ways.

First, I conclude that you are referring to this:

C:\test>p1
use Devel::Peek;;

sub toPascal{ return chr( length $_[0] ) . $_[0] };;

Dump toPascal( 'x' x $_ ) for 255, 256;;
SV = PV(0x28d280) at 0x3c599e0
  REFCNT = 1
  FLAGS = (TEMP,POK,pPOK)
  PV = 0x3cb28f8 "\377xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxx
  CUR = 256
  LEN = 264

SV = PV(0x3c3aa30) at 0x3c599c8
  REFCNT = 1
  FLAGS = (TEMP,POK,pPOK,UTF8)
  PV = 0x3cb2a28 "\304\200xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"]
  CUR = 258
  LEN = 264
[download]

Meaning has been assigned. Note the UTF8 flag is set in the second example.

But then, it makes no sense to try and create Pascal strings longer than 255 bytes, because P-strings are defined as being prefixed with a length byte.

But even if that where not the case--if length could be of any size--using SvPVbytes() wouldn't help any. Because unless the XS routine was specifically designed to work with this non-native encoding, its never going to do the right thing:

SV *func( SV *first, SV *second ) {

    return sv_catsv( first, second );
}
[download]

Just another red-herring.