I’ve recently been dipping my toes in the very deep water that is “undefined behavior” in C and C++, and the more I learn about it, the scarier it is.
This was inspired by a rather tricky crash that I needed to track down as part of moving the code-base at my day job to more modern compilers and language standards.
I recently needed to build a Linux development system from scratch, and while I was at it I decided to provide dual-boot capability between CentOS and Ubuntu.
Having used RH/CentOS pretty much exclusively since moving from Unix (Solaris) to Linux many years back, I learned that even though CentOS and Ubuntu are both Linux, they are very different in ways both large and small. I shaved a few yaks along the way, and made lots of notes – hopefully they’ll help if you’re thinking about making a similar transition.
With recent events in CentOS-land this has become even more relevant — read on to see how you can easily move back and forth between CentOS and Ubuntu.
At my day job, I spend a fair amount of time working on software reliability. One way to make software more reliable is to use memory-checking tools like valgrind’s memcheck and clang’s AddressSanitizer to detect memory errors at runtime.
But these tools are typically not appropriate to use all the time – valgrind causes programs to run much more slowly than normal, and AddressSanitizer needs a special instrumented build of the code to work properly. So neither tool is typically well-suited for production code.
But there’s another memory-checking tool that is “always on”. That tool is plain old malloc, and it is the subject of this article.
I’ve written before about static analysis, but in those earlier posts I wasn’t able to give specific examples of real-world code where static analysis is able to discover latent errors.
In the earlier articles I used a synthetic code-base from ITC Research to test clang, cppcheck and PVS-Studio. I also ran all three tools on the code-bases that I’m responsible for maintaining at my “day job”, but I wasn’t able to share detailed results from that analysis, given that the code is not public.
In this article, I want to expand the discussion of static analysis by diving into a real-world, open-source code base that I’ve been working with lately, with specific examples of the kinds of problems static analysis can expose.
I’ve been working on performance analysis recently, and a large part of that is scraping log files to capture interesting events and chart them.
I’m continually surprised by the things that you can do using plain old bash and his friends, but this latest one took the cake for me.
A while back I wrote an article that compared cppcheck and clang’s static analyzers (clang-check and clang-tidy). The folks who make PVS-Studio (the guys with the unicorn mascot that you’ve probably been seeing a lot of lately) saw the article, and suggested that I take a look at their Linux port, which was then in beta test, and write about it.
So I did. Read on for an overview of PVS-Studio, and how it compared to cppcheck.
As developers, we seem to take a special delight in personalizing the virtual worlds in which we work – from color palettes to keyboards, fonts, macros, you name it. “Off-the-rack” is never good enough, we want Saville Row tailoring for our environments.
And a lot of the tools we use support and encourage that customization, giving us control over every little option.
But not every tool we use does so – read on to learn a very simple trick to how to take control even when your tool doesn’t make that easy.
In my day job, one of my main focuses is software reliability and correctness, so it makes sense that I would be a big fan of static analysis.
I’ve written previously about the static analysis provided by clang. Today, I want to take a bit of a “deep-dive” into the whole subject by putting both clang and cppcheck through their paces, using them to analyze a benchmark suite designed to exercise static analysis tools. In the course of doing that, I’ll also provide some helper scripts that make working with the tools easier.
Nowadays it’s pretty common for applications to be distributed across multiple machines, which can be good for scalability and resilience.
But it does mean that we have more machines to monitor – sometimes a LOT more!
Read on for a handy tip that will let you do a lot of those tasks from any old session (and maybe lose some of those screens)!
I keep singing the praises of clang, and with good reason – the clang project has been advancing the state of C/C++ compiler technology on Linux and OS X for quite a while now.
The modular design of the compiler has also enabled the creation of a set of ancillary tools, including run-time “sanitizers” (which I wrote about earlier), as well as pretty-printers, and a tool to automatically upgrade code to C++11.
Today I want to talk about clang’s static analysis engine, which can do a deep-dive on your code and find problems that are hard for a human to detect, but that are amenable to a brute-force approach that models the run-time behavior of a piece of code, but at compile-time.