Rule 9: Explanation and Bugs

[philippkolbe]

In the README it says:

Rule 9. IfDividing Divide a if statement with a compound condition (∧, ∨, or ¬) into two nested if statements.

My first question how you would divide an ∨, or ¬ into two nested if statements? For ∧ it makes sense but for the others I don't understand.

Secondly, it seems like there is a bug with finding if statements with and operators. In your paper you could only find 8/9133 files where it was applicable. I have similar results in the files I'm applying SPAT on.

Faulty Example 1

Here is an example from your benchmarks where it works but only half way: https://github.com/Santiago-Yu/SPAT/blob/master/Benchmarks/9133/Original/n12914531.java

    if (sujeto.length() > 0 & verbo.length() > 0 & CD.length() > 0) {

converted to: https://github.com/Santiago-Yu/SPAT/blob/master/Benchmarks/9133/transformed/_9/n12914531.java

    if (sujeto.length() > 0 & verbo.length() > 0) {
                                        if (CD.length() > 0) {

Why would it not split this into 3 seperate if statements?

But more importantly: since & is not a lazy operator (unlike &&, see https://stackoverflow.com/questions/5564410/what-is-the-difference-between-and-in-java) this will actually produce faulty code since the code in the second if statement is not executed if the first evaluates to false. If the second if statement had side effects this could break the code.

Faulty Example 2

Original: https://github.com/Santiago-Yu/SPAT/blob/master/Benchmarks/9133/Original/n2067794.java Transformed: https://github.com/Santiago-Yu/SPAT/blob/master/Benchmarks/9133/transformed/_9/n2067794.java There are several if statements with "&&" that just remain the same

  if (wantv && (k < n - 1)) {
      for (int i = 0; i < n; i++) {
          t = V[i][k + 1];
          V[i][k + 1] = V[i][k];
          V[i][k] = t;
       }
   }

Why are they not split up? It seems like you are only splitting the ifs with "&" inbetween. As shown above that actually leads to wrong code and I don't see the reason why && could not be split into seperate if statements.

This is probably also why so few rules in the benchmarks where applicable since "&" is probably way less likely to occur than "&&".

[Santiago-Yu]

Thank you for your comment. I think I have made a mistake, according to the semantics, that all descriptions involved with & should be replaced with &&. The idea for replacing ∨ is similar to ∧ when you first swtich the if statement by a ¬. The second faulty may be caused by that I only do one modifictaion along side a sub-tree in the parse-tree. Hence, other places that is applicable will be ignored.
Anyway, the code is open-source and extremly simple, do any modification as you like~ Good luck.