C++ compile has warnings about qr-code-generator

[nayuki]

You should have stated which compiler version you are using; it would help me understand why you are getting these warning messages. From the provided text, it looks like you are using Visual C++ on Windows in the first block, and GCC on Linux in the second block. Your line numbers (e.g. BitBuffer.cpp:39, QrCode.cpp:696) are different from my reference copy. I had to use the quoted text to find the code in question. Please try to be more helpful in future bug reports, not just to me, but to anyone.

I fixed your first set of warnings in 908dbbf . I did some testing of the logic a few months ago, and found that GCC and Clang/LLVM are smart enough to understand that the 0th iteration of the loop will necessarily overwrite colorX, runX, etc. Thus it is mathematically impossible to have an uninitialized read of the variables. If I change the condition to x == 1, then GCC and LLVM correctly figure out that the variable may (will) be uninitialized before reading. I believe Visual C++ is not smart enough to figure this out, so it always gives the warning.

For the second set of warnings, I have never seen them in any compiler I used. My overall verdict is will-not-fix, because the warnings are overly pedantic (which I have not even seen using -Wpedantic on my compilers!), and the fix would make the code ugly. The crux of the three conversion warnings is the interplay between uint_8 (unsigned char) and int (int16_t or wider).

• The first warning ("BitBuffer.cpp:39") basically concerns: uint8_t |= (bool ? int : int);. However, the right side value always fits in a uint8_t.
• The second and third warnings ("QrCode.cpp:696,713") basically concern: uin8_t ^= uint8_t; The result always fits in a uint8_t. However, the expression expands to uint8_t = uint8_t ^ uint8_t, where the right side is promoted to int. This would mean I would need to write out uint8_t = static_cast<uint8_t>(uint8_t ^ uint8_t);, which only adds to the obfuscation.