Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4852317pxb; Tue, 5 Oct 2021 11:42:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxAfAlZ6JpbthjlJb0Ekvmny/VifAaNx6Tqm5PX5bC87Z0jazcE/NieVnKadtVOeBbY7vp2 X-Received: by 2002:a17:906:d54f:: with SMTP id cr15mr26575461ejc.300.1633459332398; Tue, 05 Oct 2021 11:42:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633459332; cv=none; d=google.com; s=arc-20160816; b=E9j/o2ZXMcSb1aN8HuhEyRXlBWqpDFg0E5yEwnNSxH9wCfoQFnJX7FsonwWb4okxJY +4+ifkMkD4Z6PWCa6MIWna3rfWgOgqNcUgDrY3ZZsnEEkilR9zwRYtpWGUZvVSP4Gu1u zIBy0Zza9+zC6Ie7MSzlXea3cRMHIdTPglOdxL78YnvBD3HEFTyMoewN1utBA3y1VFwL zy9jab072yPn0My9oJEURTPmu01eiL/622s5UsaC5J9N8EJz8M2b6+VRtFoBMD/y81vi UbpN3pPN8uFpAP2ktiLbZceHExUp438QgFon+w8iUxF9NKS/C+PCNiEPUrH63R1Lw273 8txQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=EW10j9TAiHURqIu8R2t9oTOU+7lMg0sh4xuxMRxdaxk=; b=YydTdUbuAzRnR43rpjxyrdlx87PKN/0+ad5JnwrAuHdxGg7x6gRAlc6J2fbsfI71t4 bQVGm8/ugsGPcV4VffuqfYSFV6nBuZ9kJPSOm7SDItZXld4/6q2+ubL5KNYXJtwPNCEP 1OEnnicYN27nJsCCpkYIJKDJWdfspIQmchRAw9i4IGzwEP08hgw+HJ05rRC/5ca2eEo8 JtensEC0K/sAtcoj97C6Sn7FpFxoU1BHqphgF5dqk7OGXEDSHxWPPBmIy5eTa0dvJeC1 L92thTgTITdlKJxocMkZ3A4RiWhPNEoMpkJrIVuExzZHV4MSSUJDlXy+q3MGcm57Xh5w dUcA== 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 g2si8535025ejt.1.2021.10.05.11.41.47; Tue, 05 Oct 2021 11:42:12 -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 S234413AbhJESl5 (ORCPT + 99 others); Tue, 5 Oct 2021 14:41:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:47730 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229662AbhJESl4 (ORCPT ); Tue, 5 Oct 2021 14:41:56 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CB861613D3; Tue, 5 Oct 2021 18:40:03 +0000 (UTC) Date: Tue, 5 Oct 2021 14:40:02 -0400 From: Steven Rostedt To: Jan Engelhardt Cc: Mathieu Desnoyers , Rasmus Villemoes , 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) * Message-ID: <20211005144002.34008ea0@gandalf.local.home> In-Reply-To: <826o327o-3r46-3oop-r430-8qr0ssp537o3@vanv.qr> References: <20211005094728.203ecef2@gandalf.local.home> <639278914.2878.1633457192964.JavaMail.zimbra@efficios.com> <826o327o-3r46-3oop-r430-8qr0ssp537o3@vanv.qr> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Oct 2021 20:28:54 +0200 (CEST) Jan Engelhardt wrote: > 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* Are you suggesting I should continue this exercise ;-) -- Steve