Sean Kelly wrote:
Was this broken condition something that could have been detected statically?
I've encountered plenty of broken conditions, but I've never had a compiler
correctly flag one such.
Yes.
if (a > C1 && a < C2) ...
where C1, C2 are compile-time constants, and C1 > C2.
(correct condition was: a > C2 && a < C1)
Sent from my iPhone
On Aug 21, 2011, at 12:39 PM, Don <nos...@nospam.com> wrote:
Sean Kelly wrote:
On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
"Bernard Helyer" <b.hel...@gmail.com> wrote in message
news:j2ithq$12kd$1...@digitalmars.com...
I asked the Ars forums ( http://arstechnica.com/civis/viewtopic.php?
f=20&t=1153378&p=21965411 ) and I ask the same of you: should
unambiguously unreachable code be an error or a warning? ( see the linked
forum post for more details ).
No. That would be a royal pain in the ass during debugging. I expect to be able to stick
a "return xxxx;" anywhere I want to test something and not have the compiler
crap out because I didn't deal with the overhead of commenting out the rest.
A warning might be nice, though.
A warning if anything. I've never encountered a situation where code was made
unreachable by accident. I also get "unreachable code" warnings periodically,
for code that is absolutely reachable. I don't want my code to not compile simply
because the compiler can't perform adequate flow analysis.
I have encountered bugs of the form:
if (cond) { /* unreachable */ }
and the cond was unintentionally always false. The last time I encountered such
a bug was last week. I'm surprised your experience is so different.
It's crucial that it should never report "unreachable" if it is unsure (not
even a warning).
But I think conditional compilation is a huge problem -- code may be valid
under different compilation conditions. I suspect that to eliminate all the
false positives, it'd have to be so conservative, that it wouldn't catch any
bugs.
