Which compiler warnings do you ignore?

Tools & Infrastructure
#1

Hello!

I’d like to get some feedback about specific compiler warnings that people often ignore (or would like to ignore) and reasons behind it.

  • Do you have some specific examples of such warnings produced by the latest compiler version? (preferably with code snippets)
  • Why don’t you just fix the warnings?
    • Are they in the code you don’t have control over?
    • Are they just false-positives? Maybe just a compiler bug?
    • Do you simply disagree with them?
    • Any other reasons?

I hope this will let us address the most problematic cases. It will also give us some input to consider whether we actually need a feature that allows disabling specific warnings. Such a feature might be convenient in individual cases but if it’s really just a half-measure to hide the symptoms and we’d rather address the cause of such problems.

1 Like
#2

Warning: Variable is shadowed in inline assembly by an instruction of the same name

I want to be able to have a SafeMath library with an add function AND use inline assembly. This is so common I’m not giving notice anymore… To a point that I’m not sure it protects me at all.

1 Like
#3

That’s a good point! Since functions cannot (at least not yet) be referenced from inline assembly anyway, there is no point in warning, I think. Would this one fix it for you? Only warn about variables being shadowed in inline assembly. by chriseth · Pull Request #10971 · ethereum/solidity · GitHub

#4

Warning: Failure condition of ‘send’ ignored. Consider using ‘transfer’ instead.

I always ignore these. Compiler thinks that transfer() is always a better alternative to send() but it’s not the case actually. In some cases, receiver of the funds is not a trusted party, and this party can make the transfer() call fail on purpose to prevent the smart contract functioning properly (a.k.a. denial of service attack). So in some cases, we don’t want the transaction revert even if beneficiary can’t receive funds.

Example scenario: A function that distributes rewards to users. It loops over a set of users, one of them is malicious and rejects the payment to make the transaction fail. Because of this nobody can receive the reward.