On 2/13/2015 9:57 AM, Dominique Devienne wrote:
Warnings are always a tradeoff between pointing out what could be
mistakes/oversights versus senseless noise.
Most times I get the unreachable warning in my code is when I'm actively
coding, experimenting, moving things around, then when I'm done I silence
them one way or another.
D'accord - but it poses an interesting dichotomy: The above is great,
however in open-source scenarios - compiling someone else's code with
your new special compiler directives where the compiler then produces
warnings which shouldn't be warnings - and then requesting the original
coder to "fix" their code - this can't ever be a useful thing.
Not 100% sure (I don't use Clang day to day), but I think I remember
reading that one way to silence this Clang warning is via extra parens, if
((bool-test)) { ... }. You're telling Clang "this one's not an oversight,
thank you". Small enough concession to having useful warnings in other
places, no? Certainly less ugly than using the preprocessor IMHO. My $0.02.
Sure, but again, having to spend energy after-the-fact on "fixing" code
that isn't broken - My vote will always be for fixing the compiler.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
