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

uint attributes behave like int #6190

Closed
p6rt opened this issue Apr 14, 2017 · 4 comments
Closed

uint attributes behave like int #6190

p6rt opened this issue Apr 14, 2017 · 4 comments
Labels
severe A problem that is encountered frequently, or a problem that needs attention for other reasons

Comments

@p6rt
Copy link

p6rt commented Apr 14, 2017

Migrated from rt.perl.org#131149 (status was 'new')

Searchable as RT131149$

@p6rt
Copy link
Author

p6rt commented Apr 14, 2017

From @zoffixznet

This appears to be a regression happened since last release, so would be beneficial to fix this before the release​:

  13​:02 c​: 2017.03,HEAD class { has uint $.x }.new​: :x(2**64-1)
  13​:02 committable6 Zoffix, ¦2017.03​: «» ¦HEAD(fbc6697)​: «Cannot unbox 64 bit wide bigint into native integer␤ in block <unit> at /tmp/EY1TW4ElM7 line 1␤ «exit code = 1»»
  13​:02 Zoffix That's got broken innit? 2*64-1 fits into uint?
  13​:03 m​: uint.Range.max.say
  13​:03 camelia rakudo-moar fbc669​: OUTPUT​: «18446744073709551615␤»
  13​:03 Zoffix m​: say 2**64-1
  13​:03 camelia rakudo-moar fbc669​: OUTPUT​: «18446744073709551615␤»

At first glance, the issue appears to be due to calling mp_count_bits on an mp_int that contains the uint value. That should either be changed
to mp_uint, if there is such a thing, or the counted bits check should be adjusted for the uint-in-a-int difference.

  13​:08 Zoffix Is there mp_uint?
  13​:08 * dogbert17 will now try with 'better-fsa'
  13​:08 Zoffix m​: class { has uint $.x }.new​: :x(2**64-1)
  13​:08 camelia rakudo-moar fbc669​: OUTPUT​: «Cannot unbox 64 bit wide bigint into native integer␤ in block <unit> at <tmp> line 1␤␤»
  13​:09 Zoffix This used to work in last release. And in this commit, we're calling count bits function on an mp_int, so it blows up​: MoarVM/MoarVM@66dd8c9#diff-7c76a26bfc12243d0362c1b3478553a8R38

@p6rt
Copy link
Author

p6rt commented Apr 14, 2017

@p6rt
Copy link
Author

p6rt commented Apr 14, 2017

From @zoffixznet

After further clarification, the issue isn't really a regression. It's just uint behaves like int and that was a bug before.

We now made out-of-range value assignment throw, so that's why 2**64-1 throws. In 2017.03 the value is accepted, but it turns into a -1

If there's already a ticket for `uint attributes behave like int` then this ticket should be just closed.

On Fri, 14 Apr 2017 06​:21​:26 -0700, cpan@​zoffix.com wrote​:

This appears to be a regression happened since last release, so would
be beneficial to fix this before the release​:

13​:02 c​: 2017.03,HEAD class { has uint $.x }.new​: :x(2**64-1)
13​:02 committable6 Zoffix, ¦2017.03​: «» ¦HEAD(fbc6697)​: «Cannot
unbox 64 bit wide bigint into native integer␤ in block <unit> at
/tmp/EY1TW4ElM7 line 1␤ «exit code = 1»»
13​:02 Zoffix That's got broken innit? 2*64-1 fits into uint?
13​:03 m​: uint.Range.max.say
13​:03 camelia rakudo-moar fbc669​: OUTPUT​: «18446744073709551615␤»
13​:03 Zoffix m​: say 2**64-1
13​:03 camelia rakudo-moar fbc669​: OUTPUT​: «18446744073709551615␤»

At first glance, the issue appears to be due to calling mp_count_bits
on an mp_int that contains the uint value. That should either be
changed
to mp_uint, if there is such a thing, or the counted bits check should
be adjusted for the uint-in-a-int difference.

13​:08 Zoffix Is there mp_uint?
13​:08 * dogbert17 will now try with 'better-fsa'
13​:08 Zoffix m​: class { has uint $.x }.new​: :x(2**64-1)
13​:08 camelia rakudo-moar fbc669​: OUTPUT​: «Cannot unbox 64 bit wide
bigint into native integer␤ in block <unit> at <tmp> line 1␤␤»
13​:09 Zoffix This used to work in last release. And in this commit,
we're calling count bits function on an mp_int, so it blows up​:
MoarVM/MoarVM@66dd8c9#diff-
7c76a26bfc12243d0362c1b3478553a8R38

@p6rt p6rt added the severe A problem that is encountered frequently, or a problem that needs attention for other reasons label Jan 5, 2020
@usev6
Copy link

usev6 commented Mar 20, 2022

From what I understand this problem is fixed by now:

$ ./rakudo-m -e 'say class { has uint $.x }.new: :x(2**64-2)'
<anon|1>.new(x => 18446744073709551614)

@niner did some major rework for uints, which no longer behave like ints. That rework certainly also fixed this particular problem. Since there were other tickets (e.g. #3740) and since a lot of tests have been unfudged recently, I'm going to close this one.

@usev6 usev6 closed this as completed Mar 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severe A problem that is encountered frequently, or a problem that needs attention for other reasons
Projects
None yet
Development

No branches or pull requests

2 participants