Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4843977pxb; Tue, 5 Oct 2021 11:30:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLATpWhzKFsKGuKl7vh6syigpn2umqi6KWgbgHbY7k0kVL6of0DNR7SweJfb0c6SBKM8Iu X-Received: by 2002:a17:903:234a:b0:13e:f01a:24f with SMTP id c10-20020a170903234a00b0013ef01a024fmr1257152plh.43.1633458610399; Tue, 05 Oct 2021 11:30:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633458610; cv=none; d=google.com; s=arc-20160816; b=EmE07oVu7lqFaGbXlH/yffXa98gB+kL0L24A444YDKWjhv6rQqrbMNtHcyZMLqt9QH 3e9vE7gHaRiptguUNL7PoZ3XEi7DP1mX/8O+QKgrJ6/wY5akNVaZCkg/P2ujQ+LZHxPe NKXLCIOJBpiFhAM74VdHLWYGmQasH8Z1Sa9viEFdmC62JVeS36sHXRYTqvlJ1Xv1R0U4 EwWBYxEbJSVeAn0ALLDMgIropSe/wh54DWp7OeB7eSNi2j3YoB3JqmLMr2qBmg+GAazv oyKTjUKf1hW13Wvv2r7IgKCjmO/qtz2Fj9ffKOjMvpWU+QKFkAxZTAHQyUC09Np0siGo 0BkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=7p+kMashd0UKTEHI7GGlRgM5CDOJXQbdxOo0rFxTBXc=; b=IcWlw/iTYx7xbt/jJgzyjK0W4WUF1Kk0tHeZz/E74ajY+ictTNg/o2KWPRZv7GzFMW EvJ4yOEfXO5uiuYm+VkUGgV7Ds4MxQ9n3nDUBgtBP8fRjk7A0DCxQhZIWdXuS2qglAl9 j9Nf1fb17B+HHowUxdX09dWCZuBGIw6HFzEKMEVU+bSECFZ8BKq5kdOsZCb1iRNOMeDg 1g1l50lBi+sXQ7rBH3Zzn/g3vbgbhHneGLzwBFb37yX+2Hf/5w+gccQEz6ePyKoX8Ia6 sfmFZ2/8RjDNdu/fFjMbxUCT0tHJl1HjfVLhKjlp/ZBfwdLOONdVpbwhKucIoFGC5N0m +2gQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s2si22989130plq.267.2021.10.05.11.29.58; Tue, 05 Oct 2021 11:30:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234405AbhJESat (ORCPT + 99 others); Tue, 5 Oct 2021 14:30:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45698 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229626AbhJESas (ORCPT ); Tue, 5 Oct 2021 14:30:48 -0400 Received: from a3.inai.de (a3.inai.de [IPv6:2a01:4f8:10b:45d8::f5]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66465C061749; Tue, 5 Oct 2021 11:28:57 -0700 (PDT) Received: by a3.inai.de (Postfix, from userid 25121) id 9FB465877C256; Tue, 5 Oct 2021 20:28:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a3.inai.de (Postfix) with ESMTP id 9C8A260C1CB34; Tue, 5 Oct 2021 20:28:54 +0200 (CEST) Date: Tue, 5 Oct 2021 20:28:54 +0200 (CEST) From: Jan Engelhardt To: rostedt cc: Mathieu Desnoyers , Rasmus Villemoes , rostedt , linux-kernel , Linus Torvalds , Paul , Josh Triplett , Lai Jiangshan , "Joel Fernandes, Google" , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , rcu , netfilter-devel , coreteam , netdev Subject: Re: [RFC][PATCH] rcu: Use typeof(p) instead of typeof(*p) * In-Reply-To: <639278914.2878.1633457192964.JavaMail.zimbra@efficios.com> Message-ID: <826o327o-3r46-3oop-r430-8qr0ssp537o3@vanv.qr> References: <20211005094728.203ecef2@gandalf.local.home> <639278914.2878.1633457192964.JavaMail.zimbra@efficios.com> User-Agent: Alpine 2.25 (LSU 592 2021-09-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 2021-10-05 20:06, Mathieu Desnoyers wrote: >> instead of just "typeof(p)", to force the decay to a pointer. > >If the type of @p is an integer, (p) + 0 is still valid, so it will not >prevent users from passing an integer type as argument, which is what >the current implementation prevents. > >Also, AFAIU, the compiler wants to know the sizeof(p) in order to evaluate >(p + 0). Steven's goal is to hide the structure declaration, so that would >not work either. >>>> typeof(*p) *________p1 = (typeof(*p) *__force)READ_ONCE(p); #define static_cast(type, expr) ((struct { type x; }){(expr)}.x) typeof(p) p1 = (typeof(p) __force)static_cast(void *, READ_ONCE(p)); Let the name not fool you; it's absolutely _not_ the same as C++'s static_cast, but still: it does emit a warning when you do pass an integer, which is better than no warning at all in that case. *flies away*