Skip to content
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

Huge repeat counts are considered as negative numbers (‘a’ x 9999999999999999999) #5279

Closed
p6rt opened this issue Apr 30, 2016 · 6 comments

Comments

@p6rt
Copy link

p6rt commented Apr 30, 2016

Migrated from rt.perl.org#128035 (status was 'resolved')

Searchable as RT128035$

@p6rt
Copy link
Author

p6rt commented Apr 30, 2016

From @AlexDaniel

Code​:
say �a� x 9999999999999999999

Result​:
repeat count (-8446744073709551617) cannot be negative
  in block <unit> at -e line 1

What's interesting is that there is a check in place​:

Code​:
say �a� x 999999999999999999

Result​:
repeat count > 1073741824 arbitrarily unsupported...
  in block <unit> at -e line 1

Also, with even bigger numbers we get this​:

Code​:
say �a� x 99999999999999999999

Result​:
Cannot unbox 67 bit wide bigint into native integer
  in block <unit> at -e line 1

But the problem is that nqp​::unbox_i returns a negative number​:

Code​:
use nqp; say nqp​::unbox_i 9999999999999999999

Result​:
-8446744073709551617

And that's probably why it is considered to be negative when using [x].

Also see this​:

Code​:
use nqp; say nqp​::unbox_i(2 ** 64-1)

Result​:
-1

Which is probably how it is supposed to work, but it looks like the check in [x] operator has to be done earlier.

@p6rt
Copy link
Author

p6rt commented Sep 9, 2016

From @MasterDuke17

On Sat Apr 30 03​:37​:46 2016, alex.jakimenko@​gmail.com wrote​:

Code​:
say �a� x 9999999999999999999

Result​:
repeat count (-8446744073709551617) cannot be negative
in block <unit> at -e line 1

What's interesting is that there is a check in place​:

Code​:
say �a� x 999999999999999999

Result​:
repeat count > 1073741824 arbitrarily unsupported...
in block <unit> at -e line 1

Also, with even bigger numbers we get this​:

Code​:
say �a� x 99999999999999999999

Result​:
Cannot unbox 67 bit wide bigint into native integer
in block <unit> at -e line 1

But the problem is that nqp​::unbox_i returns a negative number​:

Code​:
use nqp; say nqp​::unbox_i 9999999999999999999

Result​:
-8446744073709551617

And that's probably why it is considered to be negative when using
[x].

Also see this​:

Code​:
use nqp; say nqp​::unbox_i(2 ** 64-1)

Result​:
-1

Which is probably how it is supposed to work, but it looks like the
check in [x] operator has to be done earlier.

I submitted a Rakudo PR (rakudo/rakudo#867), but after some discussion with jnthn (http://irclog.perlgeek.de/perl6-dev/2016-09-08#i_13173728), it looks like the PR may be obsoleted once a fix is applied in MoarVM.

@p6rt
Copy link
Author

p6rt commented Sep 9, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Mar 28, 2017

From @samcv

I submitted a Rakudo PR (rakudo/rakudo#867),
but after some discussion with jnthn (http://irclog.perlgeek.de/perl6-
dev/2016-09-08#i_13173728), it looks like the PR may be obsoleted once
a fix is applied in MoarVM.

PR has been merged in as of MoarVM/MoarVM@ad44958 and is now in Moar blead. Unfudging the test for MoarVM. Is this still an issue for JVM? I see
#?rakudo.jvm skip 'OutOfMemoryError​: Java heap space'

@p6rt
Copy link
Author

p6rt commented May 6, 2017

From @MasterDuke17

The JVM x method was aligned with the MoarVM version in Raku/nqp#358. It can't handle values to repeat as large as MoarVM can, but that's an issue with the JVM itself that would have to be worked around.

Resolving this as I believe the original errors have been addressed. Anything new can be a new ticket.

@p6rt
Copy link
Author

p6rt commented May 6, 2017

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

@p6rt p6rt closed this as completed May 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant