Collecting runtime errors (crashes, failed assertions, …) is very important part of software quality efforts. If you know crash details from your testing team you can handle them even before a tester writes first line of error report (!). That improves development speed.
Probably the fastest method how to create KISS (Keep It Simple Stupid) central crash report repository is to use:
Dereferencing NULL pointer is a very common programming error in almost any programming language that supports pointers. It cannot be caught at build time in general, so we can carefully check every pointer before dereference and handle errant cases in runtime (warning in log?).
But above method is a runtime method. If you don’t have proper code coverage by tests it might not detect errant cases. I believe the answer for this issue lies in static methods (performed at build/before runtime phase). Good example of such approach is LCLint:
char firstChar2 (/*@null@*/ char *s)
{
if (isNull (s)) return '\0';
return *s;
}
As you can see LCLint uses annotations to mark parameter that might have NULL value and thus can detect dereferencing NULL. But LCList is only designed for C language and cannot check C++ (C++ is more complicated for parsing).
If you are merging/cherry-picking changes frequently between GIT branches it’s very useful to know exactly what changes were already merged, what changes are waiting for merge and for wchich change there will be a conflict during merge.
This information should be available from “git log“, but unfortunately I dif not get good results (even with –cherry-pick). Then some other solution must be prepared.
I decided to create a small script that will perform series of cherry-picks and prepare a report that shows integration status. Usage is pretty simple:
$ git-merge-status SHA1..SHA2
Powered by WordPress