Check return value of [must-check-caller-address]

[pscott]

[must-check-caller-address] finds the calls to get_caller_address and warns the user about it.

Ideally, this rule should NOT emit any warning if the user checks the return value. E.g.:

let (address) = get_caller_address()
if address == 0: # returned values is compared to 0
  return () # Could be any other code
end

The above code should NOT emit a warning, as the return value of get_valler_address is checked against 0.

A second example of code that should not emit a warning would be the usage of assert_not_zero:

let (address) = get_caller_address()
assert_not_zero(address)

Indeed, address will be compared (asserted) to 0.

An example of code that SHOULD emit a warning would be:

let (address) = get_caller_address()
call_contract(contract_address=address, ...)

Indeed, the return value is NOT checked against 0.

[fcasal]

Hi @pscott, indeed this is something we would like to improve the current rule on. Currently, there is no direct way of doing control-flow analysis with Amarna, and validating if the returned value is checked in a successor node like an if statement or an assert before being used would not be easy. Thanks for raising the issue, as this will serve to track progress on this end.

[0xLucqs]

since txs have to go through an account contract wouldn't it make sense to disable this rule by default ?

[pscott]

since txs have to go through an account contract wouldn't it make sense to disable this rule by default ?

I don't think transactions have to go through an account contract :) See for example, in a deploy_transaction :)

[0xLucqs]

Yes right ! Not for long hopefully :)

[james-miller-93]

the same point applies to overflow checking on things like uint256_add, for example:

let (total: Uint256, carry: felt) = uint256_add(a, b);
with_attr error_message("OVERFLOW") {
    assert carry = 0;
}