Actually, you can make a good argument for doing the calculation in the code precisely because it lets the code do the calculations and not the error-prone human that is trying to modify/maintain the code.Great suggestion, @WBahn ! I see where you are going.
I must admit that I’m confounded by the effort in eliminating these warnings. As my grandfather might say, they’re constants for cripes sake! There’s no reason not to perform the calculation manually and define the variable in the code as a const with a value of 160 (decimal). If you want to remember how that value was determined, the correct place is not in the code but with a comment.
Keep in mind that most compilers will evaluate the constant at compile time, so there is no runtime penalty in having an expression calculate the final value.
I would make the constants that might change constant-like macros or make it a function-like macro with the constant value as the argument.
Beyond that, however, trying to understand exactly why this compiler is throwing this warning is of value, particularly if you are going to be using this compiler in the future, so that you can better understand what is actually causing warnings to be thrown so that you can better determine whether it is really telling you something you need to pay attention to in a particular instance and, if it isn't, how you can best make the warning go away in the least kludgy way. I ascribe to the opinion that code should compiler warning free (using the most restrictive warning level that is tolerable). Only when absolutely unavoidable should warnings be accepted and documented.

