mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-11 08:08:06 -05:00
2fd2f4715d
I did a horrible thing with a list macro which builds up a 256-bit bitmap of known SSH-2 message types at compile time, by means of evaluating a conditional expression per known message type and per bitmap word which boils down to (in pseudocode) (shift count in range ? 1 << shift count : 0) I think this is perfectly valid C. If the shift count is out of range, then the use of the << operator in the true branch of the ?: would have undefined behaviour if it were executed - but that's OK, because in that situation, the safe false branch is executed instead. But when the whole thing is a compile-time evaluated constant expression, the compiler can prove statically that the << in the true branch is an out-of-range shift, and at least some compilers will warn about it verbosely. The same compiler *could* also prove statically that that branch isn't taken, and use that to suppress the warning - but at least clang does not. The solution is the same one I used in shift_right_by_one_word and shift_left_by_one_word in mpint.c: inside the true branch, nest a second conditional expression which coerces the shift count to always be in range, by setting it to 0 if it's not. This doesn't affect the output, because the only cases in which the output of the true branch is altered by this transformation are the ones in which the true branch wasn't taken anyway. So this change should make no difference to the output of this macro construction, but it suppresses about 350 pointless warnings from clang.