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

Issue with BigInt.asUintN #1573

Open
tonygermano opened this issue Aug 22, 2024 · 6 comments
Open

Issue with BigInt.asUintN #1573

tonygermano opened this issue Aug 22, 2024 · 6 comments
Labels
bug Issues considered a bug Ecma Incompatibility Issues about Rhino being incompatible with the EcmaScript spec good first issue Great place to start if you're looking to start an open source "resume"

Comments

@tonygermano
Copy link
Contributor

Expected:

BigInt.asUintN(64, -1n) === BigInt("0xffffffffffffffff")

Actual:

BigInt.asUintN(64, -1n) === -1n
@p-bakker p-bakker added bug Issues considered a bug Ecma Incompatibility Issues about Rhino being incompatible with the EcmaScript spec labels Aug 22, 2024
@gaurav-chaurasia
Copy link

gaurav-chaurasia commented Aug 24, 2024

Hi @tonygermano

I would like to address this issue. According to the documentation, BigInt.asUintN() is supposed to truncate a BigInt value to the specified number of least significant bits and return that value as an unsigned integer. As mentioned in the documentation: MDN Web Docs on BigInt.asUintN.

Based on this documentation, the expected result for BigInt.asUintN(64, -1n) should be the 64-bit unsigned representation of -1n, which in hexadecimal is 0xffffffffffffffff.

However, the actual result suggests that the function may not be correctly handling negative values. Instead of converting -1n to its unsigned 64-bit representation, the function appears to be returning the original signed value, -1n.

@p-bakker p-bakker added the good first issue Great place to start if you're looking to start an open source "resume" label Aug 24, 2024
@p-bakker
Copy link
Collaborator

Sounds like a good first issue then 🙂

I'm sure there are tests in the test262 sure right now marked as failing for this (although I haven't looked)

@p-bakker
Copy link
Collaborator

p-bakker commented Sep 6, 2024

@gaurav-chaurasia based on your comment, I concluded that you'd try to create a PR to fix this issue. Just checking in to see how things are going

@tonygermano
Copy link
Contributor Author

I've been kind of living in the spec recently. I haven't created the fix yet, but I do know how to fix this one. Part of the reason I started with #1611 was because so many of the BigInt tests were failing due to the lack of Symbol.toPrimitive being implemented correctly.

@gaurav-chaurasia
Copy link

@gaurav-chaurasia based on your comment, I concluded that you'd try to create a PR to fix this issue. Just checking in to see how things are going

Yes yes, I'm relatively new to open source and the Rhino engine, so I'm still getting familiar with the codebase and documentation. I've successfully built Rhino locally, and most tests have passed. However, I am not able to reproduce the issue yet as I'm facing some issues while running the Test262 suite.

@p-bakker / @tonygermano I'd really appreciate any suggestions or guidance you might have. Thank you! :)

@p-bakker
Copy link
Collaborator

p-bakker commented Sep 8, 2024

What are the issues you're running into running the Test262 suite?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issues considered a bug Ecma Incompatibility Issues about Rhino being incompatible with the EcmaScript spec good first issue Great place to start if you're looking to start an open source "resume"
Projects
None yet
Development

No branches or pull requests

3 participants