Typically people use a tool that accounts for blank lines and comments when counting the lines of code. In Karlsruhe we've always used sloccount for our measurements (including for the code base being compared to). And yes, headers and macros aree accounted for as well.
That said, there are a number of other factors that drive up the line count. For example, in Pistachio there are currently two implementations of the mapping database (keeping track of mapping relationships). The old obsolete code has not been backed out yet because some of the architectures have not yet been converted to using the new code. This accounts for about 1000 sloc. Then there are a number of assertions and tracing/debugging features spread all around that do not contribute to any functionality (and is often not even compiled in) but that accounts for a few more thousand sloc. Of course, other projects also have debug features that must be accounted for --- Pistachio is not unique in that respect. All I'm saying is that even when using tools such as sloccount, it still won't tell you the whole story.
Lastly, the sloccount of a project also heavily depends on the coding style being used. Personally I favour a style where I don't try to cram as much as possible into a single line. For example, in Pistachio we always write:
if (...) { }
rahter than:
if (...) { }
Using the latter approach, i.e., not accounting for the '{' lines, would save us more than 3000 sloc over the whole Pistachio kernel tree (not counting the kernel debugger). Clearly, such a simple change in coding style does not have any effect on the complexity of the code. It does add quite a bit of overhead to the sloccount though.
eSk
[Wei Shen]
My observation is that kernels (inc. Minix3, Fiasco, and Pistachio) are often (sometimes much) larger than the official data. Maybe, they take different estimation methods? Or maybe the data are out of date? How about the headers and macros (which can notably influence loc.)?
I wonder if it can help if someone will measure and publish the loc. of these kernels with an unified and open standard. Of course, complete comparison between L4 and Minix3 is more valuable.