From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 92F1D3858C39 for ; Fri, 14 Oct 2022 03:30:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92F1D3858C39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665718227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=sJViMFRnO8c87klKNsNS4iW++8TegtWWOsYN1FFh6Bo=; b=Geaooc2wfrV5g1zT0wwG4q2ApjT+UFeoY0XeLSV8R+qte85IA0V6NzE/PI+m74hnJe8TmB swAP0cwlbRrwPcET802TYMyTkTS7QzPkLk3vAT+TJdTtYo5AdL3GGloO+U068H79Xv6pKF WVFbGMPjn8opCmAMuYmF/Bc0h8smRTo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-57-3iXgNlP9MyyYM8IjXDUt1w-1; Thu, 13 Oct 2022 23:30:25 -0400 X-MC-Unique: 3iXgNlP9MyyYM8IjXDUt1w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 20A47800B30 for ; Fri, 14 Oct 2022 03:30:25 +0000 (UTC) Received: from greed.delorie.com (unknown [10.22.8.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0AF5285791; Fri, 14 Oct 2022 03:30:25 +0000 (UTC) Received: from greed.delorie.com.redhat.com (localhost [127.0.0.1]) by greed.delorie.com (8.15.2/8.15.2) with ESMTP id 29E3UEdR165509; Thu, 13 Oct 2022 23:30:14 -0400 From: DJ Delorie To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 2/3] Introduce , extracted from In-Reply-To: Date: Thu, 13 Oct 2022 23:30:14 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Florian Weimer via Libc-alpha writes: > +++ b/sysdeps/generic/pointer_guard.h > +#ifndef __ASSEMBLER__ > +# define PTR_MANGLE(x) (void) (x) > +# define PTR_DEMANGLE(x) (void) (x) > +#endif These macros will always be called standalone, i.e. inline uintptr_t demangle_ptr (uintptr_t x) { PTR_DEMANGLE (x); return x; } If that's the expectation, is there a reason why we need to even reference X at all? Would an empty declaration be valid? This should only affect volatile variables, but those would be referenced shortly after anyway. Atomic boundaries aren't an issue as atomics are not used in the mangling compuation. I can see having a non-empty body as a valid way to validate the usage, but in that case something that actually validates it makes more sense by only accepting a LHS: > +# define PTR_MANGLE(x) (void) (&(x)) (the non-generic usages should enforce this through their assignments) Also, is there any case where code could be corrupted by the lack of overall parens? I.e. is this better: > +# define PTR_MANGLE(x) ((void) (x))