On 10/08/2023 15.17, Andy Shevchenko wrote: > On Thu, Aug 10, 2023 at 11:09:20AM +0200, Rasmus Villemoes wrote: >> On 10/08/2023 10.15, Petr Mladek wrote: > > ... > >>> + prolonging the list of #include lines in .c file. It will >>> not help with maintainability which was one of the motivation >>> in this patchset. >> >> We really have to stop pretending it's ok to rely on header a.h >> automatically pulling in b.h, if a .c file actually uses something >> declared in b.h. [Of course, the reality is more complicated; e.g. we >> have many cases where one must include linux/foo.h, not asm/foo.h, but >> the actual declarations are in the appropriate arch-specific file. >> However, we should not rely on linux/bar.h pulling in linux/foo.h.] > > Btw, it's easy to enforce IIUC, i.e. by dropping > > #ifndef _FOO_H > #define _FOO_H > #endif > > mantra from the headers. > No, you can't do that, because some headers legitimately include other headers, often for type definitions. Say some struct definition where one of the members is another struct (struct list_head being an obvious example). Or a static inline function. We _also_ don't want to force everybody who includes a.h to ensure that they first include b.h because something in a.h needs stuff from b.h. So include guards must be used. They are a so well-known idiom that gcc even has special code for handling them: If everything in a foo.h file except comments is inside an ifndef/define/endif, gcc remembers that that foo.h file has such an include guard, so when gcc then encounters some #include directive that would again resolve to that same foo.h, and the include guard hasn't been #undef'ed, it doesn't even do the syscalls to open/read/close the file again. Rasmus
