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

Weird behaviour in a series of if-else branches #3644

Closed
ppoliani opened this issue Nov 30, 2023 · 2 comments
Closed

Weird behaviour in a series of if-else branches #3644

ppoliani opened this issue Nov 30, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@ppoliani
Copy link

ppoliani commented Nov 30, 2023

Aim

I have a series of nested if-else blocks. In each branch I assign a value to a variable based on the branch condition.

Expected Behavior

I would expect only of the branches to execute as it is the case in if-else conditions.

Bug

I'm experiencing something with I'm struggling to get my head around.

I've to the following function:

global UPPERCASEOFFSET: u8 = 65;
global LOWERCASEOFFSET: u8 = 71;
global DIGITOFFSET: u8 = 4;

pub fn get_char_for_index(index: u8) -> Option<u8> {
  let mut ascii_index = Option::none();

  if index >= 0 & index <= 25 {
    std::println(index);
    // A-Z
    ascii_index = Option::some(index + UPPERCASEOFFSET);
  } else {
    if index >= 26 & index <= 51 {
      // a-z
      ascii_index = Option::some(index + LOWERCASEOFFSET);
    } else {
      if index >= 52 & index <= 61 {
        // 0-9
        std::println(">>>>>>>>>>>>>>>>>>>>>>>>");
        ascii_index = Option::some(index - DIGITOFFSET);
      } else {
        if index == 62 {
          ascii_index = Option::some(43);
        } else {
          if index == 63 {
            ascii_index = Option::some(47);
          }
        }
      }
    }
  };

  ascii_index
}


#[test]
fn test_get_char_for_index() {
  let value: [u8] = [0, 10, 25, 26, 35, 51, 52, 55, 61, 62, 63];
  let expected: [u8] = [65, 75, 90, 97, 106, 122, 48, 51, 57, 43, 47];

  for i in 0..11 {
    let result = Option::unwrap(get_char_for_index(value[i]));
    assert(result == expected[i]);
  }

  let result = get_char_for_index(64);
  assert(Option::is_none(result));
}

The test passes which is cool. However, when I call this function from another context I get some weird behaviour.

I'm sharing the console output which shows the logs:

[base64] Testing encode::test_encode_with_trailing_equal... 0x10
0x14
0x09
0x11
0x00
Failed assertion: 'attempt to subtract with overflow'
error: Assertion failed: 'attempt to subtract with overflow'
   ┌─ /Users/ppoliani/code/apocentre/zk/noir/noir-libs/base64/src/classic.nr:23:36
   │
23 │         ascii_index = Option::some(index - DIGITOFFSET);
   │                                    -------------------

The function is called with the following u8 integers
[16, 20, 9, 17, 0]

It crashes on the last value (which is 0). As you can see in the logs though, when the value is 0, it enters the first if (index >= 0 & index <= 25) but for some reason it then end ups entering the nested statement where the panic happens.

What is interesting though is that the println is not even executed within that branch.

I'm not sure if it's a bug or I'm doing something fundamentally wrong.

To Reproduce

  • The code for the circuit is here.

Run the tests in the root base64 folder.

nargo test --show-output --package base64 --silence-warnings test_encode_with_trailing_equal

Installation Method

Binary

Nargo Version

nargo 0.19.2 (git version hash: 47f0130)

Additional Context

No response

Would you like to submit a PR for this Issue?

No

Support Needs

No response

@ppoliani ppoliani added the bug Something isn't working label Nov 30, 2023
@github-project-automation github-project-automation bot moved this to 📋 Backlog in Noir Nov 30, 2023
@TomAFrench
Copy link
Member

Hi @ppoliani, this looks to be a duplicate of #3493 which was fixed in #3494.

You can fix this issue by updating to 0.19.3 or above.

@TomAFrench TomAFrench closed this as not planned Won't fix, can't repro, duplicate, stale Nov 30, 2023
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Noir Nov 30, 2023
@ppoliani
Copy link
Author

Hi @ppoliani, this looks to be a duplicate of #3493 which was fixed in #3494.

You can fix this issue by updating to 0.19.3 or above.

Oh thank @TomAFrench. I can confirm it works now. Sorry, I missed #3493.

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
Archived in project
Development

No branches or pull requests

2 participants