www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should unreachable code be considered an error?

reply Bernard Helyer <b.helyer gmail.com> writes:
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 ).
Aug 18 2011
next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
http://bit.ly/ojnbwj

For those newsreaders that have trouble with the full link.
Aug 18 2011
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 18/08/2011 12:44, Bernard Helyer wrote:
 http://bit.ly/ojnbwj

 For those newsreaders that have trouble with the full link.

It's _your_ newsreader that had trouble with it - just viewed the source and there is indeed a line break there. But thanks. Stewart.
Aug 19 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/18/2011 01:37 PM, Bernard Helyer wrote:
 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 ).

The trouble with making dead code an error in general is that the compiler is not able to detect dead code in most cases. If it is considered an error, each instance of dead code that the compiler cannot detect could be considered an accepts-invalid bug. Also, since the compiler is allowed to assume that any assert(0); is dead code, assert(0) would always be a compile time error. =) if(__ctfe){ // dead code during runtime goes here }else{ // dead code during compile time goes here } But I think making goto label; statement; label: An error would imho be ok, if you think it is worth the deviation from the reference implementation.
Aug 18 2011
next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On Thu, 18 Aug 2011 14:14:08 +0200, Timon Gehr wrote:

The trouble with making dead code an error in general is that the
compiler is not able to detect dead code in most cases.

I'm talking about the unambiguous cases, the ones where a basic block has no parents (i.e. there is no way to enter that code block).
 Also, since the compiler is allowed to assume that any assert(0); is
 dead code, assert(0) would always be a compile time error. =)

No, only if statements followed the assert(0) (which marks the control flow block as terminated, just like return).
Aug 18 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/18/2011 02:19 PM, Bernard Helyer wrote:
 On Thu, 18 Aug 2011 14:14:08 +0200, Timon Gehr wrote:

 The trouble with making dead code an error in general is that the
 compiler is not able to detect dead code in most cases.

I'm talking about the unambiguous cases, the ones where a basic block has no parents (i.e. there is no way to enter that code block).
 Also, since the compiler is allowed to assume that any assert(0); is
 dead code, assert(0) would always be a compile time error. =)

No, only if statements followed the assert(0) (which marks the control flow block as terminated, just like return).

I was half joking. Fact is, if assert(0); is not dead code, the program is in error.
Aug 18 2011
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 18/08/2011 13:19, Bernard Helyer wrote:
<snip>
 I'm talking about the unambiguous cases, the ones where a basic block has
 no parents (i.e. there is no way to enter that code block).

So essentially you're looking to catch cases where, if you consider the function as a flow chart, there is no chain of arrows from the start of the function to the statement in question. That should be straightforward. But you're not worrying about catching cases where some arrow would never be followed. Have I got that right? <snip>
 No, only if statements followed the assert(0) (which marks the control
 flow block as terminated, just like return).

Not sure whether it should be allowed to be used e.g. to prevent execution of code that is under construction. Stewart.
Aug 19 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 20/08/2011 07:28, Bernard Helyer wrote:
 On Sat, 20 Aug 2011 01:42:56 +0100, Stewart Gordon wrote:

 So essentially you're looking to catch cases where, if you consider the
 function as a flow chart, there is no chain of arrows from the start of
 the function to the statement in question.  That should be
 straightforward.  But you're not worrying about catching cases where
 some arrow would never be followed.  Have I got that right?

Pretty much, minor correction on the last part -- an arrow means that the compiler considers it a possibility, so it's not considered in so far as the data structure doesn't make the distinction.

That's more or less what I meant. The compiler can't identify all arrows that will never be followed - this would mean solving the halting problem. So it takes the view that any arrow _may_ be followed. But if there's no arrow at all leading to a statement, the compiler can easily see that it's unreachable and so issue a warning/error. Stewart.
Aug 22 2011
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2011-08-22 21:27:39 +0000, Stewart Gordon <smjg_1998 yahoo.com> said:

 On 20/08/2011 07:28, Bernard Helyer wrote:
 On Sat, 20 Aug 2011 01:42:56 +0100, Stewart Gordon wrote:
 
 So essentially you're looking to catch cases where, if you consider the
 function as a flow chart, there is no chain of arrows from the start of
 the function to the statement in question.  That should be
 straightforward.  But you're not worrying about catching cases where
 some arrow would never be followed.  Have I got that right?

Pretty much, minor correction on the last part -- an arrow means that the compiler considers it a possibility, so it's not considered in so far as the data structure doesn't make the distinction.

That's more or less what I meant. The compiler can't identify all arrows that will never be followed - this would mean solving the halting problem. So it takes the view that any arrow _may_ be followed. But if there's no arrow at all leading to a statement, the compiler can easily see that it's unreachable and so issue a warning/error.

But what about templates? Take this pretty reasonable function template: bool frontEquals(R, V)(R range, V value) { if (range.empty) return false; else return range.front == value; } This will work fine with most ranges, but if you encounter an infinite range (with empty defined as "enum empty = false") then the "return false" statement becomes unreachable and you'll get an error/warning? It doesn't make sense. Or perhaps we should require the above to be written like this: bool frontEquals(R, V)(R range, V value) { static if (!range.isInifinite) if (range.empty) return false; return range.front == value; } But isn't that messy? And I'm dealing with only one possibility here… what if a range was always empty? Something else to care about. Thankfully I'm only checking a boolean property limited to two values. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 24 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 25/08/2011 02:41, Michel Fortin wrote:
<snip>
 bool frontEquals(R, V)(R range, V value)
 {
     if (range.empty)
         return false;
     else
         return range.front == value;
 }

 This will work fine with most ranges, but if you encounter an infinite range
(with empty
 defined as "enum empty = false") then the "return false" statement becomes
unreachable and
 you'll get an error/warning? It doesn't make sense.

The structure of a flowchart is not affected by the values of variables, or even constants, in it. _____________ ( frontEquals ) ¯¯¯¯¯¯|¯¯¯¯¯¯ ______________ ______v______ ( return false )<--- true ---< range.empty > ¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯|¯¯¯¯¯¯ false | ______________v______________ ( return range.front == value ) ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Replacing "range.empty" with "false" doesn't magically cause the true arrow to vanish. Stewart.
Aug 29 2011
parent reply Don <nospam nospam.com> writes:
On 29.08.2011 15:29, Stewart Gordon wrote:
 On 25/08/2011 02:41, Michel Fortin wrote:
 <snip>
 bool frontEquals(R, V)(R range, V value)
 {
 if (range.empty)
 return false;
 else
 return range.front == value;
 }

 This will work fine with most ranges, but if you encounter an infinite
 range (with empty
 defined as "enum empty = false") then the "return false" statement
 becomes unreachable and
 you'll get an error/warning? It doesn't make sense.

The structure of a flowchart is not affected by the values of variables, or even constants, in it. _____________ ( frontEquals ) ¯¯¯¯¯¯|¯¯¯¯¯¯ ______________ ______v______ ( return false )<--- true ---< range.empty > ¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯|¯¯¯¯¯¯ false | ______________v______________ ( return range.front == value ) ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Replacing "range.empty" with "false" doesn't magically cause the true arrow to vanish. Stewart.

Isn't: if (false) {...} unreachable code? If it doesn't create an error, what would?
Aug 31 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 31/08/2011 09:56, Don wrote:
<snip>
 What if range.empty is simply the compile-time constant 'false'?

That's exactly the case I've just covered.
 Isn't:
 if (false) {...}
 unreachable code?
 If it doesn't create an error, what would?

doSomething(); return; doSomethingElse(); including more complicated equivalents like if (condition) { return something; } else { return somethingElse; } doSomethingElse(); Stewart.
Sep 18 2011
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 20/09/2011 09:17, Rory McGuire wrote:
 Perhaps a warning, there are to many ways to make "unreachable" code
reachable. In other
 words, it is surely too much work to implement currently.

If the compiler can optimise away code that will never run because no arrow in the flowchart leads to it, why can't it just as well generate an error on the same code? Simply because we can't rely on every compiler to perform even the most basic cases of DCE? Stewart.
Oct 02 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/2/2011 2:18 PM, Stewart Gordon wrote:
 Simply because we can't rely on every compiler to perform even the most basic
 cases of DCE?

Consider: if (a) { ... code ... } Sometimes, when debugging, I'll do: if (0 && a) { ... code ... } to temporarily disable it. Should that be made illegal? If so, what about: const X = 0; if (X && a) { ... code ... } Illegal too? What about: bool foo() { ... } if (foo() && a) { ... code ... } where foo() may be evaluatable at compile time. How far should this go?
Oct 02 2011
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 02/10/2011 22:41, Walter Bright wrote:
 On 10/2/2011 2:18 PM, Stewart Gordon wrote:
 Simply because we can't rely on every compiler to perform even the most basic
 cases of DCE?

Consider: if (a) { ... code ... } Sometimes, when debugging, I'll do: if (0 && a) { ... code ... }

I was talking about cases of DCE that are even more basic than this, such as: void qwert() { return; yuiop(); } void asdfg() { if (hjkl) { return zxcvb; } else { return nm; } qaz(); } These are exactly what I mean by no arrow leading to a given statement. In your examples, OTOH, the arrow exists - it will just never be followed. Stewart.
Oct 11 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
On Sat, 20 Aug 2011 01:42:56 +0100, Stewart Gordon wrote:

 So essentially you're looking to catch cases where, if you consider the
 function as a flow chart, there is no chain of arrows from the start of
 the function to the statement in question.  That should be
 straightforward.  But you're not worrying about catching cases where
 some arrow would never be followed.  Have I got that right?

Pretty much, minor correction on the last part -- an arrow means that the compiler considers it a possibility, so it's not considered in so far as the data structure doesn't make the distinction.
Aug 19 2011
prev sibling next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
--20cf307814f43fcec404ad5b173c
Content-Type: text/plain; charset=UTF-8

Perhaps a warning, there are to many ways to make "unreachable" code
reachable. In other words, it is surely too much work to implement
currently.
Plus I find it annoying in Java when that happens, because often I'm just
quickly testing a different return.

-Rory

On Mon, Sep 19, 2011 at 2:06 AM, Stewart Gordon <smjg_1998 yahoo.com> wrote:

 On 31/08/2011 09:56, Don wrote:
 <snip>

 What if range.empty is simply the compile-time constant 'false'?

That's exactly the case I've just covered. Isn't:
 if (false) {...}
 unreachable code?
 If it doesn't create an error, what would?

doSomething(); return; doSomethingElse(); including more complicated equivalents like if (condition) { return something; } else { return somethingElse; } doSomethingElse(); Stewart.

--20cf307814f43fcec404ad5b173c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Perhaps a warning, there are to many ways to make &quot;unreachable&quot; c= ode reachable. In other words, it is surely too much work to implement curr= ently.<div>Plus I find it annoying in Java when that happens, because often= I&#39;m just quickly testing a different return.<br> <div><br></div><div>-Rory<br><br><div class=3D"gmail_quote">On Mon, Sep 19,= 2011 at 2:06 AM, Stewart Gordon <span dir=3D"ltr">&lt;<a href=3D"mailto:sm= jg_1998 yahoo.com">smjg_1998 yahoo.com</a>&gt;</span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex;"> On 31/08/2011 09:56, Don wrote:<br> &lt;snip&gt;<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What if range.empty is simply the compile-time constant &#39;false&#39;?<br=

<br> That&#39;s exactly the case I&#39;ve just covered.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Isn&#39;t:<br> if (false) {...}<br> unreachable code?<br> If it doesn&#39;t create an error, what would?<br> </blockquote> <br> =C2=A0 =C2=A0doSomething();<br> =C2=A0 =C2=A0return;<br> =C2=A0 =C2=A0doSomethingElse();<br> <br> including more complicated equivalents like<br> <br> =C2=A0 =C2=A0if (condition) {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0return something;<br> =C2=A0 =C2=A0} else {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0return somethingElse;<br> =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0doSomethingElse();<br><font color=3D"#888888"> <br> Stewart.<br> </font></blockquote></div><br></div></div> --20cf307814f43fcec404ad5b173c--
Sep 20 2011
prev sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Good point.
Dead branch isn't a problem IMO.
In the worst case it's gonna make the binary a few bytes longer.
It's not worth all the effort of trying to make the compiler complain about=
 it.
Besides, it is often required to disable a branch for debugging
purposes, although in those cases I'd rather use a more obvious
solution, like version(none) or /+ +/.

On Mon, Oct 3, 2011 at 1:41 AM, Walter Bright
<newshound2 digitalmars.com> wrote:
 On 10/2/2011 2:18 PM, Stewart Gordon wrote:
 Simply because we can't rely on every compiler to perform even the most
 basic
 cases of DCE?

Consider: =A0 if (a) { ... code ... } Sometimes, when debugging, I'll do: =A0 if (0 && a) { ... code ... } to temporarily disable it. Should that be made illegal? If so, what about=

 =A0 const X =3D 0;
 =A0 if (X && a) { ... code ... }

 Illegal too? What about:

 =A0 bool foo() { ... }
 =A0 if (foo() && a) { ... code ... }

 where foo() may be evaluatable at compile time. How far should this go?

Oct 02 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
Faramir on the Ars forums makes an excellent point:

"With the c preprocessor, both theoretically and as it is used in 
practice, you can easily get dead code in certain compile paths that is 
live in others."

I think template mixins can achieve the same sort of shenanigans. I think 
warning it is.
Aug 18 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
Faramir on the Ars forums makes an excellent point:

"With the c preprocessor, both theoretically and as it is used in 
practice, you can easily get dead code in certain compile paths that is 
live in others."

I think template mixins can achieve the same sort of shenanigans. I think 
warning it is.
Aug 18 2011
prev sibling next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
Faramir on the Ars forums makes an excellent point:

"With the c preprocessor, both theoretically and as it is used in 
practice, you can easily get dead code in certain compile paths that is 
live in others."

I think template mixins can achieve the same sort of shenanigans. I think 
warning it is.
Aug 18 2011
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
Faramir on the Ars forums makes an excellent point:

"With the c preprocessor, both theoretically and as it is used in 
practice, you can easily get dead code in certain compile paths that is 
live in others."

I think template mixins can achieve the same sort of shenanigans. I think 
warning it is.
Aug 18 2011
parent Bernard Helyer <b.helyer gmail.com> writes:
Sigh. Sorry about that. The NG is being really flakey -- I only clicked 
send once. 
Aug 18 2011
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
Faramir on the Ars forums makes an excellent point:

"With the c preprocessor, both theoretically and as it is used in 
practice, you can easily get dead code in certain compile paths that is 
live in others."

I think template mixins can achieve the same sort of shenanigans. I think 
warning it is.
Aug 18 2011
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 18/08/2011 13:38, Bernard Helyer wrote:
 Faramir on the Ars forums makes an excellent point:

 "With the c preprocessor, both theoretically and as it is used in
 practice, you can easily get dead code in certain compile paths that is
 live in others."

 I think template mixins can achieve the same sort of shenanigans. I think
 warning it is.

Definitely a warning, I get a lot of dead code during development - making it an error would be annoying, I only care about the dead code when it gets to release/commit time and I'm cleaning the code up. -- Robert http://octarineparrot.com/
Aug 18 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/18/2011 02:38 PM, Bernard Helyer wrote:
 Faramir on the Ars forums makes an excellent point:

 "With the c preprocessor, both theoretically and as it is used in
 practice, you can easily get dead code in certain compile paths that is
 live in others."

 I think template mixins can achieve the same sort of shenanigans. I think
 warning it is.

You mean string mixins? As string mixins are so much more expressive than C macros, one should actually almost never get trivial dead code in well designed string mixins.
Aug 18 2011
parent reply Don <nospam nospam.com> writes:
Timon Gehr wrote:
 On 08/18/2011 02:38 PM, Bernard Helyer wrote:
 Faramir on the Ars forums makes an excellent point:

 "With the c preprocessor, both theoretically and as it is used in
 practice, you can easily get dead code in certain compile paths that is
 live in others."

 I think template mixins can achieve the same sort of shenanigans. I think
 warning it is.

You mean string mixins? As string mixins are so much more expressive than C macros, one should actually almost never get trivial dead code in well designed string mixins.

Yes, the equivalent to the C preprocessor is version statements. Obviously anything wrapped in a version(none) block shouldn't generate an "unreachable code" error...
Aug 18 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/19/2011 8:30 AM, maarten van damme wrote:
 any released executable should not contain unreachable code.

Statically unreachable code is removed by the optimizer.
Aug 22 2011
prev sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
--000e0cd147127d379004aadd6ae2
Content-Type: text/plain; charset=ISO-8859-1

Why not a warning but when compiling using the -release flag throw an error?
Sounds logical to me as unreachable code can be there because of
debugging,etc but any released executable should not contain unreachable
code.

2011/8/18 Don <nospam nospam.com>

 Timon Gehr wrote:

 On 08/18/2011 02:38 PM, Bernard Helyer wrote:

 Faramir on the Ars forums makes an excellent point:

 "With the c preprocessor, both theoretically and as it is used in
 practice, you can easily get dead code in certain compile paths that is
 live in others."

 I think template mixins can achieve the same sort of shenanigans. I think
 warning it is.

You mean string mixins? As string mixins are so much more expressive than C macros, one should actually almost never get trivial dead code in well designed string mixins.

Yes, the equivalent to the C preprocessor is version statements. Obviously anything wrapped in a version(none) block shouldn't generate an "unreachable code" error...

--000e0cd147127d379004aadd6ae2 Content-Type: text/html; charset=ISO-8859-1 Why not a warning but when compiling using the -release flag throw an error?<div>Sounds logical to me as unreachable code can be there because of debugging,etc but any released executable should not contain unreachable code.<br> <br><div class="gmail_quote">2011/8/18 Don <span dir="ltr">&lt;<a href="mailto:nospam nospam.com">nospam nospam.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div><div></div><div class="h5">Timon Gehr wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 08/18/2011 02:38 PM, Bernard Helyer wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Faramir on the Ars forums makes an excellent point:<br> <br> &quot;With the c preprocessor, both theoretically and as it is used in<br> practice, you can easily get dead code in certain compile paths that is<br> live in others.&quot;<br> <br> I think template mixins can achieve the same sort of shenanigans. I think<br> warning it is.<br> </blockquote> <br> You mean string mixins?<br> As string mixins are so much more expressive than C macros, one should actually almost never get trivial dead code in well designed string mixins.<br> </blockquote> <br></div></div> Yes, the equivalent to the C preprocessor is version statements.<br> Obviously anything wrapped in a version(none) block shouldn&#39;t generate an &quot;unreachable code&quot; error...<br> </blockquote></div><br></div> --000e0cd147127d379004aadd6ae2--
Aug 19 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Bernard Helyer" <b.helyer 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.
Aug 18 2011
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:

 "Bernard Helyer" <b.helyer gmail.com> wrote in message=20
 news:j2ithq$12kd$1 digitalmars.com...
 I asked the Ars forums ( http://arstechnica.com/civis/viewtopic.php?
 f=3D20&t=3D1153378&p=3D21965411 ) and I ask the same of you: should
 unambiguously unreachable code be an error or a warning? ( see the =


 forum post for more details ).

No. That would be a royal pain in the ass during debugging. I expect =

 able to stick a "return xxxx;" anywhere I want to test something and =

 have the compiler crap out because I didn't deal with the overhead of=20=

 commenting out the rest.
=20
 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.=
Aug 19 2011
parent reply Don <nospam nospam.com> writes:
Sean Kelly wrote:
 On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
 
 "Bernard Helyer" <b.helyer 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 ).

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.
Aug 21 2011
parent Don <nospam nospam.com> writes:
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 <nospam nospam.com> wrote:
 
 Sean Kelly wrote:
 On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
 "Bernard Helyer" <b.helyer 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 ).

A warning might be nice, though.


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.


Aug 23 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Was this broken condition something that could have been detected statically=
?  I've encountered plenty of broken conditions, but I've never had a compil=
er correctly flag one such.

Sent from my iPhone

On Aug 21, 2011, at 12:39 PM, Don <nospam nospam.com> wrote:

 Sean Kelly wrote:
 On Aug 18, 2011, at 10:29 AM, Nick Sabalausky wrote:
 "Bernard Helyer" <b.helyer gmail.com> wrote in message news:j2ithq$12kd$=



 I asked the Ars forums ( http://arstechnica.com/civis/viewtopic.php?
 f=3D20&t=3D1153378&p=3D21965411 ) and I ask the same of you: should
 unambiguously unreachable code be an error or a warning? ( see the link=




 forum post for more details ).




ave the compiler crap out because I didn't deal with the overhead of comment= ing out the rest.
=20
 A warning might be nice, though.



dically, 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.
=20
 I have encountered bugs of the form:
 if (cond) { /* unreachable */ }
 and the cond was unintentionally always false. The last time I encountered=

=20
 It's crucial that it should never report "unreachable" if it is unsure (no=

 But I think conditional compilation is a huge problem -- code may be valid=

false positives, it'd have to be so conservative, that it wouldn't catch an= y bugs.
=20

Aug 22 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Aug 23, 2011, at 6:04 AM, Don wrote:

 Sean Kelly wrote:
 Was this broken condition something that could have been detected =


never had a compiler correctly flag one such.
=20
 Yes.
=20
 if (a > C1 && a < C2) ...
=20
 where C1, C2 are compile-time constants, and C1 > C2.
 (correct condition was: a > C2 && a < C1)

Huh=85 perhaps the issue is simply that I don't tend to have many = complex conditionals involving comparisons with numeric constants. The = tricky ones most often involve the result of at least one function call, = and I suspect there's little that can be statically determined about = those.=
Aug 24 2011