New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Malformed UTF-8 character in bitwise xor when using $1 #9972
Comments
From perl@marc-s.deThis is a bug report for perl from perl@marc-s.de, #!/usr/bin/perl -w use warnings; #No errors when using bytes!!! #Unicode bug my $unicodestring = "\x{5454}\x{6655}"; print "First we need \$1 to be unicode, otherwise the bug won't occour:\n"; print "\nNow we take 8 Bytes of a normal string with m/(.{8})/\n"; $normalstring=~/(.{8})/; my $x=$1 ^ $iv; print "How come 2 non UTF-8 flagged scalars suddenly turn into UTF-8 when a previously UTF-8 flagged \$1 is involved?\n"; print "This will not happen if we copy \$1 first into another variable or print \$1 before the operation\nThen the UTF-8 Flag will be removed\n"; # The problem occours in Net::SNMP's encrypt_des routine. Flags: Site configuration information for perl v5.8.8: Configured by Debian Project at Fri Dec 19 00:43:54 EST 2008. Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Locally applied patches: @INC for perl v5.8.8: Environment for perl v5.8.8: |
From zefram@fysh.orgperl@marc-s.de (via RT) wrote:
In that case Net::SNMP has a bug. Bitwise ^ on a string containing -zefram |
The RT System itself - Status changed from 'new' to 'open' |
From @ap* Zefram <zefram@fysh.org> [2009-11-20 11:20]:
Is it a sane operation at all? Should it be permitted? Silently? (Wondering aloud.) Regards, |
From @ikegamiOn Thu, Nov 19, 2009 at 4:14 PM, perl@marc-s.de (via RT) <
I can't replicate the behaviour you describe in 5.8.0 (had to get is_utf8
No: Now the UTF-8 Flag of $1 is off: UTF8-Flag($1): 1
No warning
No: $x is now UTF-8: UTF8-Flag ($x):
No: $iv suddenly is also UTF-8: UTF8-Flag ($iv):
|
From @dcollinsnI am able to partially reproduce this on 5.8.8, even less partially reproduce it on 5.10 and 5.12, and it appears to have been "fixed" in 5.14. My 5.8.8 differs from the reporter's in that $1 never stops being UTF8. In 5.10.0, the bitwise warning disappears, and nothing is UTF8 after that line. In 5.14.0, $1 stops being UTF8 as well 1) UTF-8 flag of $1 after m// +----------------------+---+---+---+---+---+---+ I'm choosing not to bisect this because there are at least two steps to this fix, and perl versions before 5.12ish don't build on my computer without manual assistance. It does appear that all the issues raised by this ticket have been resolved in every currently maintained perl. -- |
@dcollinsn - Status changed from 'open' to 'resolved' |
From @xsawyerxOn 08/17/2016 05:12 PM, Dan Collins via RT wrote:
If it's fixed in all the supported versions (heck, since 5.14), I don't |
From @TuxOn Wed, 17 Aug 2016 17:15:11 +0200, Sawyer X <xsawyerx@gmail.com> wrote:
For completeness sake: $ cat rt70652.pl my $unicodestring = "\x{5454}\x{6655}"; # First we need $1 to be unicode, otherwise the bug won't occur my @t; # $1 is assigned but not yet unicode: UTF8-Flag ($1) # After we copy $1 the Flag is on: UTF8-Flag ($1) # Now we take 8 Bytes of a normal string with m/(.{8})/ $normalstring =~ m/(.{8})/; # The UTF-8 Flag of $1 is still on: UTF8-Flag ($1) # Now the UTF-8 Flag of $1 is off: UTF8-Flag ($1) my $x = $1 ^ $iv; print join ":" => $], @t, "\n"; 5.6.0 .. 5.8.0 will warn and die: 5.8.1 .. 5.8.8 will warn: $ perl-all rt70652.pl | & grep ^5 | sort -u -- |
From @xsawyerx[Top-posted] We can still add this test as a regression test. On 08/17/2016 05:46 PM, H.Merijn Brand wrote:
|
@dcollinsn - Status changed from 'resolved' to 'open' |
Migrated from rt.perl.org#70652 (status was 'open')
Searchable as RT70652$
The text was updated successfully, but these errors were encountered: