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
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 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
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.


<snip>

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.


 <snip>

 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.


What if range.empty is simply the compile-time constant 'false'?
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 Rory McGuire <rjmcguire gmail.com> writes:
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.
Sep 20 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.


<snip top of upside-down reply>

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
next 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 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 ... }


<snip>

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:
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 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 reply maarten van damme <maartenvd1994 gmail.com> writes:
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...
Aug 19 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 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
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 =




linked

 forum post for more details ).


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


to be=20

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


not=20

 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 ).


 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.
Aug 21 2011
parent reply 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$=






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 link=








ed

 forum post for more details ).


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






e able to stick a "return xxxx;" anywhere I want to test something and not h=
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.


 A warning if anything.  I've never encountered a situation where code was=




 made unreachable by accident.  I also get "unreachable code" warnings perio=
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=


 such a bug was last week. I'm surprised your experience is so different.

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


t 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 an=
y bugs.

=20
Aug 22 2011
parent reply 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 ).


 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.
Aug 23 2011
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 =




statically?  I've encountered plenty of broken conditions, but I've =
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