So, clang has a static analyser. This effectively builds and does a deep analysis on the resultant binary for possible coding errors such as memory loss, dead code, etc. I've always run dhcpcd using valgrind, a memory debugger which has (and still does!) served me well over the years alongside hard compiler warning flags. So I thought dhcpcd will be pretty good after running it through the analyser.
Boy was I wrong!
Well, not wrong, but a tiny bit annoyed. It did catch some false positives, but only because I know some conditions are impossible but could be better expressed so the pass the analyser. here is a good example of what I mean. The 1st two changes don't change anything in the real world, but do make the code easier to read and thus easier to analyse.
However, it has caught some real errors which can could problems in the real world. Nothing really earth shattering, but I like being a perfectionist! During this process I also discovered that hard coding CC in Makefiles can be a bad thing. So we now just honour CC as set by the environment and default to using the make default or cc if not set.
So to test clang analyser on the latest dhcpcd head you can do this
./configure make clean scan-build make
and check the results!
dhcpcd has a lot of global variables. For a traditional UNIX environment this makes a lot of sense, when working as a single master daemon or in a daemon per interface model. But for a threaded model, this is very very bad because you then have competing threads wanting the same global resource. It Just Won't Work. Now threading has no place in dhcpcd because it's just plain silly.
However ..... how about dhcpcd running in a pure threaded single process environment as found in Real Time OSs? Now it becomes more interesting because you can no longer use signalling and you really are restricted to a single shot dhcpcd controlling all interfaces. It could be argued that not having any global variables is just a better programming practice, but I'm not entirely sold on that one.
Anyway, I've recently committed quite a large patch to dhcpcd which passes a context to a functions which would otherwise have none so that every single function and operation can safely work in a threads based environment.
Now, I need to improve the control socket so that the dhcpcd commandline works the same way entirely without signals. fun times!