Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <37faa9c7-94a3-3ea1-f116-6ff5cdf021cd@rasmusvillemoes.dk>
Date:   Thu, 10 Aug 2023 16:17:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends
Content-Language: en-US, da
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Petr Mladek <pmladek@suse.com>, Marco Elver <elver@google.com>,
        linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
        linux-mm@kvack.org, Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Alexander Potapenko <glider@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Andrew Morton <akpm@linux-foundation.org>
References: <20230805175027.50029-1-andriy.shevchenko@linux.intel.com>
 <20230805175027.50029-3-andriy.shevchenko@linux.intel.com>
 <ZNEHt564a8RCLWon@alley> <ZNEJQkDV81KHsJq/@smile.fi.intel.com>
 <ZNEJm3Mv0QqIv43y@smile.fi.intel.com> <ZNEKNWJGnksCNJnZ@smile.fi.intel.com>
 <ZNHjrW8y_FXfA7N_@alley> <ZNI5f+5Akd0nwssv@smile.fi.intel.com>
 <ZNScla_5FXc28k32@alley>
 <67ddbcec-b96f-582c-a38c-259234c3f301@rasmusvillemoes.dk>
 <ZNTjbtNhWts5i8Q0@smile.fi.intel.com>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
In-Reply-To: <ZNTjbtNhWts5i8Q0@smile.fi.intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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