5 ms·

When I saw this title, I was expecting to find something about using a computer to detect things like "use after free" errors. However, skimming the paper, it a

When I saw this title, I was expecting to find something about using a computer to detect things like "use after free" errors. However, skimming the paper, it appears to refer to altering the source code to remedy compile-time errors rather than to finding flaws in program logic. The notion of the authors is to repair broken inputs so that they compile correctly despite syntax errors by the programmer. I don't think this is a particularly useful thing to do. Essentially it is somewhat like making a compiler which accepts broken inputs using heuristics to guess at what the programmer intended to write. That will not result in better programs being written, rather it will result in the programmer not only writing worse code but not even being aware of the flaws in their code.

make3 9y ago
I think that what was attractive here is that the training set is very easy to generate, as you just take a bunch of existing code and break it at random places, and then feed the network the original code as a Ground Truth. Creating a corpus of "use after free" that's big enough would take forever.
marvy 9y ago
Obviously you don't want silent autocorrect. You use this to get suggested corrections when things don't compile.
- Safety1stClyde 9y ago
  > You use this to get suggested corrections when things don't compile. It repeatedly says that the aim is to fix errors. Assuming, however, that it is intended to give better error messages, here is the output of Clang on the input C program given as an example: $ cc gupta.c gupta.c:3:5: warning: incompatible redeclaration of library function 'pow' [-Wincompatible-library-redeclaration] int pow(int a, int b); ^ gupta.c:3:5: note: 'pow' is a builtin with type 'double (double, double)' gupta.c:14:23: error: function definition is not allowed here int pow(int a, int b){ ^ gupta.c:18:14: error: expected ';' at end of declaration return res;} ^ ; gupta.c:18:14: error: expected '}' gupta.c:4:11: note: to match this '{' int main(){ ^ 1 warning and 3 errors generated. It identifies the problematic line of the program code better than gcc. The function declaration within main is not legal. I tried this with the gcc compiler and did not get the error above. Running "indent" on the code would have revealed the problems: $ indent < gupta.c /INDENT Error@18: Stuff missing from end of file */ A simple count of braces, { and }, would also have revealed the problem.
  - marvy 9y ago
    So you're saying this whole paper could have been avoided if they just used clang. And it seems you're right.
- shriphani 9y ago
  A simple way to get suggestions is to take your finite state machine (that consumes tokens) to a special error state and just analyze what got you there. You'll pick up quite a lot of errors.
userbinator 9y ago
It reminds me of this: https://github.com/mattdiamond/fuckitjs https://github.com/mattdiamond/fuckitjs

make3 9y ago

I think that what was attractive here is that the training set is very easy to generate, as you just take a bunch of existing code and break it at random places, and then feed the network the original code as a Ground Truth. Creating a corpus of "use after free" that's big enough would take forever.

marvy 9y ago

Obviously you don't want silent autocorrect. You use this to get suggested corrections when things don't compile.

Safety1stClyde 9y ago
> You use this to get suggested corrections when things don't compile. It repeatedly says that the aim is to fix errors. Assuming, however, that it is intended to give better error messages, here is the output of Clang on the input C program given as an example: $ cc gupta.c gupta.c:3:5: warning: incompatible redeclaration of library function 'pow' [-Wincompatible-library-redeclaration] int pow(int a, int b); ^ gupta.c:3:5: note: 'pow' is a builtin with type 'double (double, double)' gupta.c:14:23: error: function definition is not allowed here int pow(int a, int b){ ^ gupta.c:18:14: error: expected ';' at end of declaration return res;} ^ ; gupta.c:18:14: error: expected '}' gupta.c:4:11: note: to match this '{' int main(){ ^ 1 warning and 3 errors generated. It identifies the problematic line of the program code better than gcc. The function declaration within main is not legal. I tried this with the gcc compiler and did not get the error above. Running "indent" on the code would have revealed the problems: $ indent < gupta.c /INDENT Error@18: Stuff missing from end of file */ A simple count of braces, { and }, would also have revealed the problem.
- marvy 9y ago
  So you're saying this whole paper could have been avoided if they just used clang. And it seems you're right.
shriphani 9y ago
A simple way to get suggestions is to take your finite state machine (that consumes tokens) to a special error state and just analyze what got you there. You'll pick up quite a lot of errors.

userbinator 9y ago

It reminds me of this: https://github.com/mattdiamond/fuckitjs https://github.com/mattdiamond/fuckitjs