4 ms·

Diffing C header files has way more false negatives than just "adding a function".

• flukus 8y ago
  Such as? White space changes can be ignored, comments can be stripped pre diff, both version can be run through the same formatter before hand. What you're then left with are the actual changes. Anything removed or modified is a breaking change. Anything added to a public struct is a breaking change, which can and arguably should be hidden behind an interface. Adding functions is about all I can think of that's left. Even if it's not perfect, it's a simple 90% solution with 40 year old tools.
  • earenndil 8y ago
    What if: * Function order changes * Prototype goes from int function(char * ); to int function(char * arg); * Typedef is added so instead of int function(char* );, it's typedef char* str; int function(str);
    • flukus 8y ago
      Good points, the second one in particular I don't think could be fixed without a full parser. Function order changes could possibly be worked around by a formatter/linter that can reorder functions, at the risk of creating more issues. The last could be handled be passing the code through the preprocessor (the -E flag in gcc) first. By this point it's probably gone beyond the "perfect is the enemy of good" threshold though.
      • earenndil 8y ago
        > The last could be handled be passing the code through the preprocessor (the -E flag in gcc) first Nope, that only handles preprocessor directives (essentially, any line starting with '#'). Typedefs are handled by the parser.
      • LukeShu 8y ago
        That's still going to be way "less perfect" than diffing the output of `javap` or `godoc` or probably even the `help(module)` for a Python module. The ability to diff APIs objectively gets better when we switch away from C header files.