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 AA1A7C04A6A for ; Fri, 11 Aug 2023 19:28:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 406FB6B0074; Fri, 11 Aug 2023 15:28:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B75F6B0078; Fri, 11 Aug 2023 15:28:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27F606B007B; Fri, 11 Aug 2023 15:28:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 151F46B0074 for ; Fri, 11 Aug 2023 15:28:24 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BA0CBC1228 for ; Fri, 11 Aug 2023 19:28:23 +0000 (UTC) X-FDA: 81112810086.24.9D958B1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id 01989C0027 for ; Fri, 11 Aug 2023 19:28:21 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of "SRS0=Nh2Q=D4=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=Nh2Q=D4=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691782102; a=rsa-sha256; cv=none; b=m6eTpw5JVXG/jhnwnwcGcwWBk43IqFWi8Nb6HdJ1PKHDxpMGYsDTpdQIQ/IvBg3Q1Sz/sF Vi5OB30vXllVToaB/WMShTyW7gjyzt7/jps7cSiXTeeRVj0AA4ZppdTzk/jWgy5MyQq0qP 8NU2uhUZK3GmzLF1V1jxTjCOBKWZapQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of "SRS0=Nh2Q=D4=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=Nh2Q=D4=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691782102; 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; bh=VB1SsgP/eWMfrWQCoLT7rmh3vb+lh0Mjm7Mxw7P3lcA=; b=urSmSOFDxek+G4AQNxjT0AAWvRhNm8tQX7w35kF9Eb6OyCRBAZJNOKkLo2Q0pnpjPAxbg2 DDuoJgWdCADqzM/VsSNGvJ8vefCqKJiXnVBr448fxKFDirX2p0awBIgNqY+tZ6Ol7v0M8Z ov7vKTs0RsNoQyGSRI8nZpXn3+bZ4x0= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0E313676D0; Fri, 11 Aug 2023 19:28:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21C71C433C7; Fri, 11 Aug 2023 19:28:19 +0000 (UTC) Date: Fri, 11 Aug 2023 15:28:17 -0400 From: Steven Rostedt To: Rasmus Villemoes Cc: Andy Shevchenko , Petr Mladek , Marco Elver , linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, Sergey Senozhatsky , Alexander Potapenko , Dmitry Vyukov , Andrew Morton Subject: Re: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends Message-ID: <20230811152817.010e1da3@gandalf.local.home> In-Reply-To: <37faa9c7-94a3-3ea1-f116-6ff5cdf021cd@rasmusvillemoes.dk> References: <20230805175027.50029-1-andriy.shevchenko@linux.intel.com> <20230805175027.50029-3-andriy.shevchenko@linux.intel.com> <67ddbcec-b96f-582c-a38c-259234c3f301@rasmusvillemoes.dk> <37faa9c7-94a3-3ea1-f116-6ff5cdf021cd@rasmusvillemoes.dk> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 01989C0027 X-Stat-Signature: uuzhp51dzhm3ijb3s4j5okqgabf6b3hh X-HE-Tag: 1691782101-231516 X-HE-Meta: U2FsdGVkX19YTu/IU3HPovm0PdzbHj4Xkw+wsElXVDEhMqoYiQk15ugKqyJ4J3eqljLqaaqiqsyAAgxKbo6dWb2lNxRI2EXiOVAUct25hkZlfJkrKvnwwRyCYIdIJ0GQERlRA4SLEuABWzPMnftx+3BkGxHVed9/fqn/1z/rbxTSAjjh3d8M+GvTk2Y/XF+ztQFdmok2XqAT02WxeXNo9SL+whHic8PnH8xH3avnKHSRF1kNU/7pM+thFOFyN54I5l7nBsk58lP/ANuuLUsW0LSRnr4CWefbrHodabiEBynl9ioPFqRAoItH2tQO9SL4slpX947ENRQxTtG1p+ZJVIITQAFunUuE4oeSjuBii+vPE/tcj6hmzIQU0PoBLhXn2IpFEOvk3x8nqVkQ1ep3K/BhT3/v5Z5IrWaZbRHm2wKbBQZi3ZdlOLE6GCPCv71rjMOn7c4wumz74yWpLD5oCR3+TjDKxH4VpF5pnWKgMmMVvyp5EWRRxnFoZvxVY2axrAMzUq8q8p9HUwEaLKeYm8J8TGZF3rrKNTDcg3laUI68TfoxcpRZdwCkgP/DZ8MUBXI/XcZx7xLOCe7BPjpRs8EXwvrXBa041bgHC2pSMAEZGa4I/B2dFCntQHTYrDT5Zf1fExTJL2mHLPyJvkPGh6wCYijhzxh3QLc/tWyf31eIvDayRJTpjPreCCjUX72+WHDtlSYpeivZuR+X6vUHh2A09A/CCnm+0+sdL3K0/6V/JbvCL3aT0FW9TlfxSGcsFeBwYbPnEmsAUNifch4dMaudVOWnBJ8wWB1EKAREKBKNZCiu+Ii3po3Ri8OJT3Wlzw8JTCiVdROl64/I6syeHYyae2oayekQYJi7Qh7ehhz/p14LDJGdN7FD/kOYvxZezCPiSK14pZFQqT1w4sfkNhzqQx357N0XhCvad9FJdwoNH5TLEFyx8C9/kVyyqjNxG3rdMdv7+bl90nNXPLr v0GeSEnU 4ih4IShow9TauifDrXUKXRsYxfva/bdaUWsKK29HjxAXikvh9hq4t5GxQMTV6Dv658t3YruqOa8LJvBWiROBPEMOryHKuOyISvUwTRYYfJrPz1gIScrkVLKlttt9ggztotAHHGcOLhQ3v5w8/pa7Nq9eg4+i6ZYSOxMoZHp91dA/XbzDvxWgsTgL3+ycsMP/LRI4KbZvB3ydc7pKxuMmu8I8fp99wcgacmZzUPL2e3QDcqlCB2xGJ0vpIOmEBxZnXooS525YtcI2IuKGGxvsjCMfkazpf4156TuBz3BdmtQQV67aJ69G/wTc/7oQSwse4fuSz17kVQIlwoLqv26oT5ujEK07V5+959GYE 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 Thu, 10 Aug 2023 16:17:57 +0200 Rasmus Villemoes wrote: > > 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. I hope Andy was just joking with that recommendation. -- Steve