3 ms·

I, at one time, worked on a tool, commercial and external to the compiler, that did this (among other things). Probably the most intellectually challenging job

I, at one time, worked on a tool, commercial and external to the compiler, that did this (among other things). Probably the most intellectually challenging job I have ever had. I am happy static analysis makes inroads into mainstream! Few takeaways from that time: inter procedural matters: if your function reallocated a pointer passed as an argument, you want to treat it as ‘free’ regarding this argument, and conversely, if your function returns a newly allocated memory, you want to mark it as such, and so on. There is also a trade off between the breadth of the analysis and the human ability to comprehend it, author mentions 110 node path in the article. The subject of my unfinished PhD thesis and something I hope also picks up is the combination of static and dynamic analysis, used iteratively. If your static analysis flags a suspicious path but does not have the means to figure out if it is true or not, instrument it and leave it to the dynamic analysis to run through it (the idea here that total instrumentation a la valgrind is detrimental to performance so you will get some gain from selective instrumentation). Conversely, dynamic analysis may provide some hints as to where static analysis should be applied at a greater depth and provide automatic annotation of functions with regard to their behaviour and - possibly - invariants, that help with the state explosion.

DyslexicAtheist 7y ago
ca 2000 - 2004 I had the luck to work on a massive C/C++code base building base station / telecoms infrastructure. We had several hundred engineers contributing code with all kind of different philosophies (many grey beards who did C/C++ for decades). Running Flexelint was part of our CI chain and also part of the internal coding standard (e.g. definition of done). There was no other time in my life where I learned so much about secure coding as I did back then. Biggest challenge was agreeing about false positives and we had 1 guy in the team who maintained the official wiki document on when a lint warning needed to go on a whitelist with an agreed description of why. The initial overhead to become lint-clean got a lot of push-back but thanks to management support we got there and you could really see how things stayed at that level even after years. It felt at times bureaucratic or like yak shaving, but in retrospect linting was what kept the code base at a quality I haven't seen ever again since. It also ensured everyone was on the same page. Taking linting seriously required a small learning curve though and lead to some discussions here or there. These discussions were really valuable since we got to really learn from another too. When I left and went to another project it felt like a step back where we were chasing the same old bugs due to bad coding practices and it was a major step back in my career as a dev. I miss those days. Really love that this becomes part of gcc.
- neilv 7y ago
  Kudos for lint-clean, and for high-quality C/C++ programming. One of my own stories of that (coincidentally, from when I worked on dev tools for aerospace/datacomm): https://news.ycombinator.com/item?id=21158546 https://news.ycombinator.com/item?id=21158546

DyslexicAtheist 7y ago

ca 2000 - 2004 I had the luck to work on a massive C/C++code base building base station / telecoms infrastructure. We had several hundred engineers contributing code with all kind of different philosophies (many grey beards who did C/C++ for decades). Running Flexelint was part of our CI chain and also part of the internal coding standard (e.g. definition of done). There was no other time in my life where I learned so much about secure coding as I did back then. Biggest challenge was agreeing about false positives and we had 1 guy in the team who maintained the official wiki document on when a lint warning needed to go on a whitelist with an agreed description of why. The initial overhead to become lint-clean got a lot of push-back but thanks to management support we got there and you could really see how things stayed at that level even after years. It felt at times bureaucratic or like yak shaving, but in retrospect linting was what kept the code base at a quality I haven't seen ever again since. It also ensured everyone was on the same page. Taking linting seriously required a small learning curve though and lead to some discussions here or there. These discussions were really valuable since we got to really learn from another too. When I left and went to another project it felt like a step back where we were chasing the same old bugs due to bad coding practices and it was a major step back in my career as a dev. I miss those days. Really love that this becomes part of gcc.

neilv 7y ago
Kudos for lint-clean, and for high-quality C/C++ programming. One of my own stories of that (coincidentally, from when I worked on dev tools for aerospace/datacomm): https://news.ycombinator.com/item?id=21158546 https://news.ycombinator.com/item?id=21158546