Skip to content

fix: fields fromstring not working as intended #7365

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.

Sign up for GitHub

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

Merged
sklppy88 merged 2 commits into from
Jul 9, 2024
Merged

fix: fields fromstring not working as intended #7365

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
337bd61
init
Jul 5, 2024
d34522f
fix: fields fromstring not working (#7366)
sklppy88 Jul 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions yarn-project/foundation/src/fields/fields.test.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,18 @@ describe('GrumpkinScalar Serialization', () => {

// Check if the deserialized instance is equal to the original
expect(deserialized).toEqual(original);

// Note odd number of digits
const arbitraryString = '123';
const arbitraryHexString = '0x123';
const expectedBigInt = 291n;

expect(GrumpkinScalar.fromString(arbitraryString).toBigInt()).toEqual(expectedBigInt);

@rahul-kothari rahul-kothari Jul 5, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't arbitary string resolve to 123 and not 291?

@sklppy88 sklppy88 Jul 5, 2024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's always resolved as hex currently, regardless of whether it's prefixed or not. Do we want to change the base behavior ?

@sklppy88 sklppy88 Jul 5, 2024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The base issue was that any string was getting truncated if it was an odd length.

@rahul-kothari rahul-kothari Jul 8, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm can we make it clear then that fromString expects a hex string?

@sklppy88 sklppy88 Jul 8, 2024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, added the comment as you specified in scrum, and refactored the check because the check didn't actually work for a hexstring like 12xx34xx56.

@olehmisar olehmisar Oct 24, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sklppy88 can this problem get revised? I am hitting this issue in a deep object, so i cant easily convert all my strings to hex format

@sklppy88 sklppy88 Oct 25, 2024 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @olehmisar: I haven't had the green light to change the current behavior, but will your problem be alleviated if I add a param for you to specify the encoding ?

@sklppy88 sklppy88 Oct 25, 2024

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See here, would this fix your problem ?

@olehmisar olehmisar Oct 25, 2024 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sklppy88 i am have to do something like this:

encodeArguments(abi, args.map((arg) => {
  if (Number.isFinite(Number(arg))) {
    return new Fr(BigInt(arg));
  }
  return arg;
}));

Now imagine that args contains a nested object or array. i will have to iterate over each object deeply (prob using recursion) to convert each number into a hex string manually.

Your example won't help as it will just change:

- return new Fr(BigInt(arg));
+ return new Fr(arg, "dec");

But if you fixed the original problem, i would be able to just write this code:

encodeArguments(abi, args)

@olehmisar olehmisar Oct 25, 2024

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please explain the reasoning behind not wanting to change it to autodetection of decimal vs hex? For me it's such an obvious decision. What am i missing?

expect(GrumpkinScalar.fromString(arbitraryHexString).toBigInt()).toEqual(expectedBigInt);

const incorrectlyFormattedString = '12xx34xx45';

expect(() => GrumpkinScalar.fromString(incorrectlyFormattedString).toBigInt()).toThrow();
});

// Test case for GrumpkinScalar.toBuffer
Expand Down