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.

Only the meaning assigned to that value:

Your demo actually shows that there is no change in meaning. It's %d or %u that controls what gets displayed, so %d and %u is what gives the value meaning.

I will grant you that there is no change in value for some purposes. i==j is true, so the value is the same as far as == is concerned. However, i<5 == j<5 is false, so the value isn't different as far as < is concerned.

It's still moot, though, since 8-bit strings are a proper subset of 32/64-bit strings.

I've been pointing out right from the very beginning, that I'm not interested in getting "the encoded version"

Exactly, and SvPVX can return the encoded version. At least without the limitation you added a couple of posts ago.

that can never be safely or logically treated as any form of unicode.

I don't know why you keep bringing up unicode.

<iand SvPVX can return the encoded version.

Gaaaaaaaaah! No it can't. It just returns a pointer to some memory. It places no interpretation upon what it is that memory. And neither does my code.

I don't know why you keep bringing up unicode.

Look again. Prior to the quoted post, I mentioned it once, and you mentioned it once.

That aside, isn't utf-8 a "form of unicode."?

---

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"