[Ksummit-discuss] Should we force include <linux/err.h> when compiling all .c files?
josh at joshtriplett.org
Fri Jul 25 23:24:29 UTC 2014
On Fri, Jul 25, 2014 at 01:39:39PM +0100, David Howells wrote:
> Should we forcibly include <linux/err.h> from the gcc command line when
> compiling all .c files? Note:
> warthog>git grep -l '#.*include.*<linux/err[.]h>' -- \*.c | wc -l
> warthog>git grep -l 'IS_ERR\|ERR_PTR\|PTR_ERR\|ERR_CAST' -- \*.c | wc -l
> So a lot fewer .c files include it than use it, but according to:
> 1: If you use a facility then #include the file that defines/declares
> that facility. Don't depend on other header files pulling in ones
> that you use.
> as pointed out to me by Stephen, it shouldn't be assumed that it's available.
> However, passing errors in pointers is so very common within the kernel, it
> might worth be adding linux/err.h to the automatically included stuff.
~/src/linux$ git grep -l 'IS_ERR\|ERR_PTR\|PTR_ERR\|ERR_CAST' -- '*.c' | wc -l
~/src/linux$ find -name '*.c' | wc -l
Functionality used by less than a quarter of the source files in the
kernel doesn't make sense to automatically include. You have a clear
test that shows whether a file uses this functionality, which would
allow an automated patch adding the necessary #include lines.
That does raise an interesting general issue, though: when a change to
the kernel would involve patching several thousand files, and would
potentially produce a huge number of conflicts (and a huge number of
patches if broken out by subsystem) if fed through the normal process,
but can be described by a very short script that requires no manual
intervention, might it make sense to have a clear procedure for saying
"Hey Linus, can you please run this script on top-of-tree and commit the
- Josh Triplett
More information about the Ksummit-discuss