# Does it make sense to require token value to be anything but negative to prevent hack (more details below...)?

I was asked to validate a smart contract for a token and a function that puzzled me looks like that:

``````     function transferFrom(address _from, address _to, uint tokens)

{
require(balanceOf[_from] >= tokens);

if (_from != msg.sender && allowance[_from][msg.sender] != uint(-8523)) {
require(allowance[_from][msg.sender] >= tokens);
allowance[_from][msg.sender] -= tokens;
}

_transfer(_from, _to, tokens);

}
``````

So the logic is: If and only if both the sender is different than _from and the approval is for anything other than -8523 then make sure _from has approved message sender to transfer the specified amount of tokens and also subtract them from the allowance.

Which of course leads to the question: is it technically possible for uint to be negative and can someone specify allowance for negative uint which is namely -8523? What if uint is send in hexadecimal or so? Thanx!

• "is it technically possible for `uint` to be negative" - No, `uint` is by definition non-negative. Nov 18, 2019 at 20:21
• thought so....yet how is this possible: ethereum.stackexchange.com/questions/69404/… Nov 18, 2019 at 20:52
• maybe he gets HUGE positive number but sends in negative.... Nov 18, 2019 at 20:52
• Read the first comment to that question (which happens to be mine, I just noticed, but it summarizes pretty well what I was thinking of writing to you when I read the title of that question). Nov 18, 2019 at 21:02
• Yeah OK so do you mean by "off chain" a client call? For example what will happen if I call it vis web3 say using python and simply send -1 to the blockchain or to the testnet (ropsten)? I guess it will be converted to the 2^256-1 or so... Nov 18, 2019 at 21:12

Some tokens use a special value in `allowance` to minimize gas fees when used in combination with `approve`/`transferFrom`.