From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46EA3C001B0 for ; Thu, 10 Aug 2023 14:18:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 689176B0071; Thu, 10 Aug 2023 10:18:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 639AE6B0072; Thu, 10 Aug 2023 10:18:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 500F86B0075; Thu, 10 Aug 2023 10:18:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 417306B0071 for ; Thu, 10 Aug 2023 10:18:06 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5938AC1067 for ; Thu, 10 Aug 2023 14:18:05 +0000 (UTC) X-FDA: 81108399330.21.DDD4053 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf03.hostedemail.com (Postfix) with ESMTP id 2A22320021 for ; Thu, 10 Aug 2023 14:18:01 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=iWBAAYJf; dmarc=none; spf=pass (imf03.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.208.179 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691677082; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ScQPJVFmfG5yKGg5DsOWT7+SxQjEiPcmHkfk8PrKVuE=; b=afIfCmjaJew9XUShlZ/PmQ/hEkvLtiN7RxxSXymoT35k2psc560EvlskrahZDQAkndfVH/ u3yv+xHgbWJMhCmd/gL+rirMKHqZ2++4j5f2Lyl0/IeYPv0ZJ/zn67mT3tXdkzFyiv6/ac w4KONo6lUYmzzg0CiN2o/FNCuy/Ml4A= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=rasmusvillemoes.dk header.s=google header.b=iWBAAYJf; dmarc=none; spf=pass (imf03.hostedemail.com: domain of linux@rasmusvillemoes.dk designates 209.85.208.179 as permitted sender) smtp.mailfrom=linux@rasmusvillemoes.dk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691677082; a=rsa-sha256; cv=none; b=olLvzUcFrpnp2Kx98qig+a99vo6S+zwMo1Gnrx0sjleBmZZW8TMMxZXY/zEOmcfiThoVGm ymL1oBiTXxheYHj/8Nqimihnu7NcYQfM2Z7Pc79BSWOzutunBVJPFqs41UQDEJYOhXDq/0 IcCoSsOC/iH+XVsZAWD2vUfDHu99bgM= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2b974031aeaso15226681fa.0 for ; Thu, 10 Aug 2023 07:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; t=1691677080; x=1692281880; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ScQPJVFmfG5yKGg5DsOWT7+SxQjEiPcmHkfk8PrKVuE=; b=iWBAAYJfmjFD5t+dtx0d3vEi3Mw0nihzMfBWohPon6ZlKKGGwxLvfK+suOec7m4WYZ ErSucSfxivToXSksb8WAS9Cz/Spoa8SxUjY7H5/FpLbwjoxAkKaVX/Aozzju+V0I3ahN g48KVvDqN8QtrU9OMaA1kvnUxRW7wBb8b302E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691677080; x=1692281880; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ScQPJVFmfG5yKGg5DsOWT7+SxQjEiPcmHkfk8PrKVuE=; b=F5gfn43RG0kKXq5F94wRTLbHsOe89zD8OqGxOxyzXxZHFAqAk2CMfG4JC4HqaZkRad Jx/1E8wS7CX2+2L5kc+5cGe/3eRmfNFKuzrLHQzW32Bx+GaTsynO3FyW0cJ3L9upss+0 iScY9dktd1p7ZAM8WXgGfg5W1dnnEzbUMyLWl48E8wUt7I0rp409tGTtjyrPH60Hf85j 7khxPq7t3old1NkEsG8Ni+59p0fZODYDCQ9kpUcaVuoyAvWPc3y5s/qcVqQHl2wsXRP5 CGomTyu62kVzOBqT8gT0OQioQqBeIB76/CM5EYzTS2jIdycm/ArtavE98kWglqM3hNht qEeg== X-Gm-Message-State: AOJu0Yz/NYNI5zCMhM6Hs6mqQR9jBuxFLf+CKUJ5dRgZfsg484saicsM UGOEMoflNhtNn4vLiCiPAPIQLw== X-Google-Smtp-Source: AGHT+IGpHiNGH9i5ecq3yxubAnt6FGtsthT0WiEcuVXtQK4exQp9jozLOhix+OOPMl0MZcKTn0zomw== X-Received: by 2002:a2e:920f:0:b0:2b9:eeaa:1072 with SMTP id k15-20020a2e920f000000b002b9eeaa1072mr2261035ljg.18.1691677079446; Thu, 10 Aug 2023 07:17:59 -0700 (PDT) Received: from [172.16.11.116] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id l19-20020a2eb693000000b002b9b9fd0f92sm363615ljo.105.2023.08.10.07.17.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Aug 2023 07:17:58 -0700 (PDT) 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 Cc: Petr Mladek , Marco Elver , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, Steven Rostedt , Sergey Senozhatsky , Alexander Potapenko , Dmitry Vyukov , Andrew Morton References: <20230805175027.50029-1-andriy.shevchenko@linux.intel.com> <20230805175027.50029-3-andriy.shevchenko@linux.intel.com> <67ddbcec-b96f-582c-a38c-259234c3f301@rasmusvillemoes.dk> From: Rasmus Villemoes In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2A22320021 X-Stat-Signature: ou51x47nca8g6ri178pshcb9kzf7ytjm X-HE-Tag: 1691677081-944315 X-HE-Meta: U2FsdGVkX1/DG4fFO4OZeRTnq2GVk053XB3met4IwGXE/yEeGxdY0Biow0MRx4e2yFIbA4ATuHsWZz84SnNuWIT3rJV2PjDg9HUAZ77nL+4I6cQ07DE4DHogjet3gdL7dUHKvPUbHaiu6kaAIFZd07fRx+Fsav2ticBL1nf5MiNNei7YdGnH3YSvAVCh1sCaKB8Qkcc6MEcaQUe4zu/fjN3VSLcaNjyg7qTj7hzILRjXOU+9bZhmBvaSFzYJ6f+1XoX/PsPQFy6xe5JP+TY7Is1Eo2ExIodzsSVX3D4NyK6eEF1AKJOCGoJhWfxJ1umTdH79TSGlo2nipX36spy+COZoUiUuGyI1Y6bsBwwLYkRDte/Q4/4C6g9TJ7/Bq1+gwDokfrmgla4eNmofI4mVGYZyPG7HnBDAu+awPq4ofxHCJ6krqt9fKnbdMj9HTdei9cWfAsRlm9ztn7aEPS5AEWDITybiv7nMuiPFl/8p8poqcsmkC+joDbU0qebce3xxx7W/hiNfuV4YBbONmDT3NgNd/3Zz50iMKHM2gcd8voyXUzDSi56FsGar/SQj4seoqoOxQOiGrrIWHUBWWg2d2aD2V4N7mGgNJarTG5MddSTKEuhGtPNKZC6/0ISFIr7jtDH36FOoKnRYzhP4MdWnObZU3NPEW/XUlN+1Tf2nSTe6TH4fIPgbTuDb89ufpM48EiUy6wmubIhmIOD4uU5rIFy4zHKbCt++kLNNHNy3p5fdVEXDbSfnMsC8Cbym6TQFUqXqWdAaGgaJRSuyf6kiyhJjgsFZ3YJHffT9MH3/pjTgiSTiewqzBIfc+8WRQe/LvLniQxS9gFYPYFePiFP8FOLjBHvgaho4GqkuFhcPjw6FqQtwncPGuHv7H73gwf9iJlepumZcBXLQh83I187EHH6+etR+umBtMD7A2ZCb0vXhw6RUcBM/H3qeLD5zADBSbJV9STRwvVEngH3ezH5 z8EJmE3P +Tap69j1cNE8rEAj9VxoUd/VOXnBwMPBxUj2ufot7CD9XTB5ax8eptwWL+FRcUxDJSWJhppq1JSZDLMVHPUD51Zcb6L9zeUfZT7K7BiTAK77SmV69Ja5d15lL7hXBkfqRinzYX/aeppzt1bbzv+g3Ue3t9U+6KwgGEOCsfRGJxZPTdWZW4u570HUGNRK8vhow6d/acdrF21DOHprNjyGdx7Mod2T12JxECBxaaAL+NIDpag5lcw6f8D2e3qa5bFV13/zBh7J0pKrlBM6y0BMPB/JiozM6ITvsZtw874a7OnlmCXQgRiR7VYSOqOLej5evKSENKLEHWVWtsahFrjXFVxBOOHtBjpBbwIrg2zbPkt+nJd8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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