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
.chop(9999999999999999999999999999999999999999999999999) does not chop #4474
Comments
From @AlexDanielCode: Result: |
From @zoffixznetFWIW, the behaviour is different now: <Zoffix> m: say 'xx'.chop(999999999999999999).perl; IMHO there's nothing to fix here and the ticket should be rejected. It's attempting to chop over an EXABYTE of data. c'mon :) |
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanielOn Sun Jun 19 16:52:30 2016, cpan@zoffix.com wrote:
First of all, this ticket is not going anywhere without tests :) Secondly, you have demonstrated that the erroneous behavior is still there. I may change the title to fit current status, but that's not a big deal. The problem is that with huge numbers the behavior is blatantly wrong. I hope you are not trying to say that 「say 'xx'.chop(9999999999999999999).perl;」 should print "xx". It doesn't really matter if the number is very high, it should not print nonsense in any case. |
From @zoffixznet
I'm saying I don't care what it does in that instance. If you're attempting to chomp an exabyte of data you already have a bug in your code and what Perl 6 does in that case is irrelevant. The problem with this ticket is it proposes we take a performance hit in *every* use of .chomp just so in a unlikely scenario of someone's buggy code stumbling on this, Perl 6 will Do The Right Thing in already-buggy code. This ticket proposes we take a performance hit for no other reason than to scratch some OCD itch of purely theoretical usecase. Even the maximum string length we support is several thousand times smaller than the chomp case described in this ticket: m: my $x = [~] (("a" x 1073741824) xx 2**16); say $x.chars |
From @zoffixznetFixed in rakudo/rakudo@94b52c1 Tests added in: |
@zoffixznet - Status changed from 'open' to 'resolved' |
From @MasterDuke17On Fri Jul 08 05:48:23 2016, cpan@zoffix.com wrote:
FWIW, I agree with the ticket that the old behavior is a bug (and not I did some informal benchmarks of .chop'ping both small and large strings perl6 -e 'my $a = "a" x 2**16;my $n = now;for ^100000 {my $b = $a.chop($_)};say now - $n' As an aside, I wouldn't mind if the max allowed size of a string was significantly increased. |
Migrated from rt.perl.org#125814 (status was 'resolved')
Searchable as RT125814$
The text was updated successfully, but these errors were encountered: