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

No overflow errors at compilation for add/sub constants operations. #4078

Open
pventuzelo opened this issue Jan 18, 2024 · 2 comments
Open
Labels
bug Something isn't working

Comments

@pventuzelo
Copy link

pventuzelo commented Jan 18, 2024

Aim

We (https://github.com/FuzzingLabs) find that the compiler fails to raise overflow errors at compilation while adding/subtracting two constants together.

Expected Behavior

The documentation explicitly states that this particular error occurs during the creation of a proof of correct execution. However, it's important to note that Noir language closely resembles Rust, and in this case, such errors are raised during the compilation process.

Bug

  1. Create a Noir project with the following command: nargo new test_issue
  2. Paste the code below into the file [main.nr](http://main.nr/)
  3. Compile the project using the following command: nargo compile
fn main() {
    // No error is raised if all static values are less than u8 max
    let var1: u8 = 255 + 1;

    // Similarly, no error is raised when using a variable with a static value
    let var: u8 = 255;
    let var2: u8 = var + var;

    // This also applies in the negative direction and other integer types
    let var3: i64 = -18446744073709551616 - 1;
}

To Reproduce

No response

Installation Method

None

Nargo Version

No response

Additional Context

No response

Would you like to submit a PR for this Issue?

No

Support Needs

No response

@pventuzelo pventuzelo added the bug Something isn't working label Jan 18, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Jan 18, 2024
@TomAFrench
Copy link
Member

Note that this behaviour is by design such that tests will still produce println output. We previously would halt compilation and return an error but that resulted in poor UX as shown in #3207.

We could restore this behaviour but would have to add an allow_unsatisfiable parameter to force creation of an invalid circuit for tests.

@asterite
Copy link
Collaborator

asterite commented Dec 4, 2024

Also Rust doesn't error in this case:

fn main() {
    let x: u8 = 255 + 1;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: 📋 Backlog
Development

No branches or pull requests

3 participants