in reply to Re^24: Interleaving bytes in a string quickly
in thread Interleaving bytes in a string quickly

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.
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"
  • Comment on Re^25: Interleaving bytes in a string quickly

Replies are listed 'Best First'.
Re^26: Interleaving bytes in a string quickly
by ikegami (Patriarch) on Mar 01, 2010 at 15:13 UTC

    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.

[reply]

      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.

      Read more... (4 kB)
      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.
[reply]
[d/l]
[select]

        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.

[reply]

In Section Seekers of Perl Wisdom