From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Tue Sep 30 18:16:55 2025 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 9001A356C22; Tue, 30 Sep 2025 18:16:55 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by www.open-std.org (Postfix) with ESMTP id 0E900356BFA for ; Tue, 30 Sep 2025 18:16:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759249013; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=YyXVEpqMr6oHc/ME0rjEJNmqz31pE/NuMuF5sLDD+VU=; b=PLVH9yqNQWmBx9JdFnSzgTotHVddfb2G4MsTOdGf+6A6TNrAIjUOprHbtUecIYnvIQMtk2 cBOMUyHGUA7vdzyFpRhiRzm8RLapyytbmq8a4UgXDOJ66wTE0OMul/fLlmjIa8oSNSvTqA PjfgW9X7d182QsG477AIboJwOcI67v4= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-623-3IgtpsN2OYujc0Os6_QyWw-1; Tue, 30 Sep 2025 12:16:51 -0400 X-MC-Unique: 3IgtpsN2OYujc0Os6_QyWw-1 X-Mimecast-MFC-AGG-ID: 3IgtpsN2OYujc0Os6_QyWw_1759249010 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-46e3dcb36a1so33882365e9.2 for ; Tue, 30 Sep 2025 09:16:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759249010; x=1759853810; h=mime-version:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YyXVEpqMr6oHc/ME0rjEJNmqz31pE/NuMuF5sLDD+VU=; b=pUfcRlNUfQJ5wsTOQCki0eUHMnrYQDk4jJQKvni5rcPe/XnagSqoM0/Y6EbNv2so5A zo6dx2x8kDS8kPA4P2AJ1Kr0rwx45dOkgwNTtO7QE3KX2UacyLcsZxBRGpdMOjvPyteu iVWQSoo/S/AENA3NSjqhnqhT7W55DGL7BpzKRc5ZbNxQ1TLQqgwUNnWWl2Kstns9b85z jHU+fw7Ck4EGKsf1yt6+e/Mr+UnRYCY5L0ksO3JL0HCxR3wfLO17Bp7Ke/fuTlYXcN7g 0zORGrW6l00osbZsTX67QDsTnpC/UMLxHZ2joL0SEM4cZF/Q8dAhmVTrXCcAXwy74elM Fq8w== X-Gm-Message-State: AOJu0YzUxtp3gxiFnKuFKSfV1ilQCO0+EE18oYAlzKnn04uBN+kQjwGH N5CcywUpG0GfGsvHEBPmdUU7VKrq/meHJE+bD+8mx8n7XQhbMK5cVhPi4HqKDgYtsaJDS7WFQFU 8yxbJHhbtg6j69pS2K13/98A5MuSe+qzCalRlcZcJeIbFFxT1JxIFza6q6hdk9pF5+z2o5zK2ep Rc34olTeQ9ehcQ9MZ3ugwShgTegDmwjvKjkzgdTbdd X-Gm-Gg: ASbGncsrJGbEUB6wsBtIGUOGzNI2GLCht3HXwWKxzTstrhNMo9QCWtnMJKJa8fhBFHd QqflrLHNx3abI6Fr+fktnGIyOJt3Vvsim89UXx/xrt4IX8cJagiT1WBPtzeaVx/W5m49kzt04pq ryatt/KU8kt+s9RQuYysoWYXVWzQf+bF1fnOJMb/VUsA6i8jwOCufCVcOy2mKuDdCt+EHJZgRF9 GwfbYhuW28VFbCyASIzycVzzdwKa0GAQ3Cv9feK20Sbo+ZBG5G9NknOwlibjzOQ7Mz+ZgIU1MgU PfiVHTtIqCCeBEtQK9ubOwHH+OoyGDA252qL5Ht+8/qeuid+zB8+qHralxfZ9A2xEDzQHaqp3qD m X-Received: by 2002:a05:600c:3543:b0:45d:d68c:2a36 with SMTP id 5b1f17b1804b1-46e61281448mr3834815e9.27.1759249009995; Tue, 30 Sep 2025 09:16:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHoctf9eMjOhLyaUtw2n+mjKiOWCHvvd3SW/npk3uam3X0S3URuv+avx47o980FfjhxTDopsQ== X-Received: by 2002:a05:600c:3543:b0:45d:d68c:2a36 with SMTP id 5b1f17b1804b1-46e61281448mr3834515e9.27.1759249009419; Tue, 30 Sep 2025 09:16:49 -0700 (PDT) Received: from digraph.polyomino.org.uk (digraph.polyomino.org.uk. [2001:8b0:bf73:93f7::51bb:e332]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46e619a8ae2sm277375e9.15.2025.09.30.09.16.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Sep 2025 09:16:48 -0700 (PDT) Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.97) (envelope-from ) id 1v3d1z-0000000GB6p-0YHL for sc22wg14@open-std.org; Tue, 30 Sep 2025 16:16:47 +0000 Date: Tue, 30 Sep 2025 16:16:47 +0000 (UTC) From: Joseph Myers To: sc22wg14@open-std.org Subject: Issues with alignas wording Message-ID: <70231bd4-a5dc-880d-ea3a-8755c56e147a@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 7OlwcwpCC4YaLJ98o5WY-kGwrHdsR_T83EbuloxJjTQ_1759249010 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Sender: owner-sc22wg14@open-std.org Precedence: bulk At the June 2024 meeting we adopted changes to the alignas specification (N3244, item 69, using the alternative wording) to reduce undefined behavior by moving some things to Constraints. I think there are still various things that are unclear / problematic in this wording (some of which were also unclear / problematic before then, but the change since C23 is significant enough it might be awkward to try to resolve this through the issue process and expect a resolution to apply to both C23 and C2Y). Paragraph number references here are to 6.7.6 in N3685. 1. Does "has an alignment specifier" include the case where there is such a specifier but all alignment specifiers in a declaration specify alignment 0 ("An alignment specification of zero has no effect.") and does "no alignment specifier" exclude that case, or are alignment specifiers specifying alignment 0 completely ignored for the purposes of such rules? This affects paragraph 6 (the new constraint from N3244), and also paragraph 9 about the case of multiple translation units. 2. I think the (new) "If the definition of an object has an alignment specifier, no declaration of the object in a different translation unit shall specify a stricter alignment." (Semantics, paragraph 9) is missing something: if the definition *doesn't* have an alignment specifier (or only has alignment specifiers with alignment 0), there must also be no stricter alignment specifiers (i.e. stricter than default; could be specified as no alignment specifiers at all) on declarations in other translation units, because such specifiers could result in code in those translation units assuming alignment not actually provided by the definition. What we have at present isn't actually implementable. 3. How do the rules in paragraph 6 apply with tentative definitions? That is, in the presence of tentative definitions, possibly with other declarations, but no explicit (initialized) definition in the translation unit, can declarations / tentative definitions with alignment specifiers be mixed with those without? We specify the type and initializer of the implicit definition in the case of tentative definitions, but we don't specify how any alignment specifier on that definition is to be determined. 4. Do I understand correctly that declarations with different alignment for an object can be mixed *provided* there is no definition for that object in that translation unit? That is, extern alignas (32) int a; extern alignas (64) int a; does not violate any constraint (provided 64 is a supported alignment for external storage duration), but adding a definition in the same translation unit would violate a constraint (at least one of the alignment specifiers would fail to match the definition), while adding a definition in another translation unit would be OK if its alignment is at least as strict? If so, the case where there's a definition in a different translation unit seems to be new in C2Y (previously UB), and it doesn't seem particularly useful to require implementations to track that there were multiple different alignments on declarations of an identifier in order to diagnose this if it gets defined, rather than just needing to track the one alignment on that identifier. Maybe paragraph 6 should be stricter (by making the first sentence apply to any two declarations in the same translation unit, not just a definition and another declaration, so two declarations of the same object in the same translation unit, both with alignment specified, must always specify the same alignment). -- Joseph S. Myers josmyers@redhat.com