if statement that, when false, skips first statement in its block, executes second?

J

Jay McGavren

`I've got some very strange behavior here involving an if statement
which, when false, skips the first statement in its block, but then
*executes the second*! I'm hoping I've made some mistake which will be
obvious to someone in the group, that I just haven't noticed yet.

Here's output from a jdb session (my comments preceded with "*"):

*The if statement is about to be evaluated:
main[1] list
54 Iterator conditions = conditionIterator();
55 boolean conditionFailed = false; //If behavior has no
conditions, it should be performed by default.
56 conditionLoop: while (conditions.hasNext()) {
57 Condition condition = (Condition) conditions.next();
58 => if (condition.isMet((GameObject) subject, (GameObject)
object) == false) {
59 conditionFailed = true;
60 break conditionLoop;
61 }
62 }
63
*As you can see, it *should* evaluate to false:
main[1] print condition.isMet((GameObject) subject, (GameObject)
object)
condition.isMet((GameObject) subject, (GameObject) object) = true
main[1] nextStep completed: "thread=main", net.sourceforge.zyps.Behavior.perform(),
line=60
bci=44
*And yet, here it is ready to execute the *second* statement
*in the if block! (Even though it skipped the first!)
60 break conditionLoop;

main[1] list
56 conditionLoop: while (conditions.hasNext()) {
57 Condition condition = (Condition) conditions.next();
58 if (condition.isMet((GameObject) subject, (GameObject)
object) == false) {
59 conditionFailed = true;
60 => break conditionLoop;
61 }
62 }
63
64 //Process all actions.
65 Iterator actions = actionIterator();

JDB was run with the command:
jdb -classpath build;test_build;C:\junit\junit.jar -sourcepath
source;test net.sourceforge.zyps.BehaviorTest

Full source can be accessed here:
Behavior:
http://cvs.sourceforge.net/viewcvs....rceforge/zyps/Behavior.java?rev=1.4&view=auto
BehaviorTest (probably not relevant):
http://cvs.sourceforge.net/viewcvs....orge/zyps/BehaviorTest.java?rev=1.4&view=auto
Entire source tree:
http://cvs.sourceforge.net/viewcvs.py/zyps/zyps/

If anyone has any ideas, they would be most appreciated!
 
M

Matt Humphrey

Jay McGavren said:
`I've got some very strange behavior here involving an if statement
which, when false, skips the first statement in its block, but then
*executes the second*! I'm hoping I've made some mistake which will be
obvious to someone in the group, that I just haven't noticed yet.

Here's output from a jdb session (my comments preceded with "*"):

<snip code / jdb trace>

In my experience, when I have observed a debugger jumping to the wrong
statements (especially around ifs, whiles, etc) it's usually because I
changed the source code and forgot to recompile / redeploy and I'm seeing
the old code execution with the new source lines.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/
 
J

Jay McGavren

Matt said:
In my experience, when I have observed a debugger jumping
to the wrong statements (especially around ifs, whiles,
etc) it's usually because I changed the source code and
forgot to recompile / redeploy and I'm seeing the old code
execution with the new source lines.

Unfortunately, this is a fresh compile. (And this problem has
persisted for a week through multiple compilations on both Windows and
Linux.) I'm certainly willing to believe that my compiled code and my
source aren't "aligned" correctly, but I don't know how to rectify
that...

I'm compiling via Ant, BTW. Here's the task:

<target name="compile" depends="initialize" description="Compile the
source">
<javac srcdir="${source_directory}" destdir="${build_directory}"
debug="on">
<classpath refid="project.class.path"/>
<!-- <compilerarg value="-Xlint:unchecked"/> -->
</javac>
</target>

http://cvs.sourceforge.net/viewcvs.py/zyps/zyps/build.xml?rev=1.2&view=auto
 
R

Roedy Green

`I've got some very strange behavior here involving an if statement
which, when false, skips the first statement in its block, but then
*executes the second*!

Errors of this sort can be avoided by these rules:

1. always enclose if and else bodies in { }. Beware particularly the
construction
if ()
if ()

2. Check for ; after if (); it should not be there. If you really
mean it write:

/* do nothing */ ;

instead.
 
O

opalpa

Neither one applies here Roedy.

Re: 1

There is only one if, so nested if statements are not an issue. Also,
a note, Kernighan writes if statements without braces.


Re: 2

It's not there.

---

Sometimes compilers implement breaks and continues wrong. There was
one time when AT&T's telephone network, about twenty five years back,
went down cause a break from a switch was implemented wrong in
compiler. Anyway, looks like a bug; perhaps rewrite the code? I
believe this code could be written more idiomatically. Idioms rarely,
if ever, compile wrong.

Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/
 
R

Roedy Green

There is only one if, so nested if statements are not an issue. Also,
a note, Kernighan writes if statements without braces.

and it is a dangerous practice for newbies.
 
T

Thomas Hawtin

Famous as a C programmer who writes compressed code with lots of
symbols, undescriptive identifiers and little compiler support.
Hopefully most of us have left that sort of stuff behind.
and it is a dangerous practice for newbies.

It's a dangerous practice for anyone.

I once spent a day or two trying to optimise an embedded system in order
to get a half-decent sound quality. Then I noticed a stray semicolon at
the end of a {}less if().

Tom Hawtin
 
R

Roedy Green

I once spent a day or two trying to optimise an embedded system in order
to get a half-decent sound quality. Then I noticed a stray semicolon at
the end of a {}less if().

I would like it if there were a lint option to insist on {} for if and
no empty statements. Algol 68 had "nihil" when you wanted an explicit
empty statement. If's without them look so innocent but do things so
different from what they first appear.

I can stare at the code for 10 minutes and still not see the problem.
 
J

Jay McGavren

Everyone, thanks for the advice, but it now appears as if this is a
case of jdb inaccurately reporting which line it is about to execute.
I placed an executable line following the if block, thusly:

conditionLoop: while (conditions.hasNext()) {
Condition condition = (Condition) conditions.next();
if (! condition.isMet((GameObject) subject, (GameObject) object)) {
conditionFailed = true;
break conditionLoop;
}
System.out.println("foobar");
}

....and when the if statement was false, it then reported that the line
it was about to execute was the println (instead of the break). A
check of the variable values suggests that no code within the if block
was ever executed.

I think I'm starting to see why very few people use jdb. When I have
time, I'm going to try out the Eclipse debugger instead. (I also
intend to make this code a little cleaner.) Thanks for the advice,
everyone!
 
A

Alan Krueger

Sometimes compilers implement breaks and continues wrong. There was
one time when AT&T's telephone network, about twenty five years back,
went down cause a break from a switch was implemented wrong in
compiler.

The one 16 years ago in 1990 was apparently due to a coding error
involving a misplaced break, not a compiler error. Did they have
another catastrophic network crash before that?

http://www.cs.berkeley.edu/~nikitab/courses/cs294-8/hw1.html
 
A

Alan Krueger

Jay said:
I think I'm starting to see why very few people use jdb. When I have
time, I'm going to try out the Eclipse debugger instead. (I also
intend to make this code a little cleaner.) Thanks for the advice,
everyone!

This may not go away with Eclipse, as I've seen related (but not
identical) things there. These strange debugger jumps are usually due
to the way the generated code is structured and how it interacts with
the line number information.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,834
Latest member
BuyCannaLabsCBD

Latest Threads

Top