top | item 14475014

(no title)

Safety1stClyde | 8 years ago

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.

discuss

order

make3|8 years 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|8 years ago

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

Safety1stClyde|8 years 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.

shriphani|8 years 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.