From @AlexDaniel

Code​:
say 'xx'.chop(999999999999999999999999999999999999999999999999).perl;
say 'xx'.chop(9999999999999999999999999999999999999999999999999).perl;

Result​:
""
"xx"

From @zoffixznet

FWIW, the behaviour is different now​:

<Zoffix> m​: say 'xx'.chop(999999999999999999).perl;
<camelia> rakudo-moar 1d93ad​: OUTPUT«""␤»
<Zoffix> m​: say 'xx'.chop(9999999999999999999).perl;
<camelia> rakudo-moar 1d93ad​: OUTPUT«"xx"␤»
<Zoffix> m​: say 'xx'.chop(99999999999999999999).perl;
<camelia> rakudo-moar 1d93ad​: OUTPUT«Cannot unbox 67 bit wide bigint into native integer␤ in block <unit> at <tmp> line 1␤␤»

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 @AlexDaniel

On Sun Jun 19 16​:52​:30 2016, cpan@​zoffix.com wrote​:

FWIW, the behaviour is different now​:

<Zoffix> m​: say 'xx'.chop(999999999999999999).perl;
<camelia> rakudo-moar 1d93ad​: OUTPUT«""␤»
<Zoffix> m​: say 'xx'.chop(9999999999999999999).perl;
<camelia> rakudo-moar 1d93ad​: OUTPUT«"xx"␤»
<Zoffix> m​: say 'xx'.chop(99999999999999999999).perl;
<camelia> rakudo-moar 1d93ad​: OUTPUT«Cannot unbox 67 bit wide bigint
into native integer␤ in block <unit> at <tmp> line 1␤␤»

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 :)

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 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.

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
rakudo-moar 94a31c​: OUTPUT«0␤»

From @zoffixznet

Fixed in rakudo/rakudo@94b52c1

Tests added in​:
Raku/roast@a222a04
and
Raku/roast@1956de4

@zoffixznet - Status changed from 'open' to 'resolved'

From @MasterDuke17

On Fri Jul 08 05​:48​:23 2016, cpan@​zoffix.com wrote​:

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.

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
rakudo-moar 94a31c​: OUTPUT«0␤»

FWIW, I agree with the ticket that the old behavior is a bug (and not
just because I submitted the PR). If I want to worry about the size of
a string I'll use C. One of the reasons I love Perl (5/6) is that I
don't have to worry about many of those kinds of things. I love that
Perl 6 gives me the option do something about it if I do care (use native),
but the freedom to not have to.

I did some informal benchmarks of .chop'ping both small and large strings
and there was no *noticeable* difference. These are what I ran for .chop with
int and Int​:

perl6 -e 'my $a = "a" x 2**16;my $n = now;for ^100000 {my $b = $a.chop($_)};say now - $n'
perl6 -e 'my $a = "a" x 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.
I looked for documentation as to the max size and why that value was chosen, but I
couldn't find anything.