From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org  Mon Feb 16 21:58:45 2026
Return-Path: <owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org>
X-Original-To: sc22wg14-domo2
Delivered-To: sc22wg14-domo2@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id DB970356D49; Mon, 16 Feb 2026 21:58:45 +0100 (CET)
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 669D1356CF8
	for <sc22wg14@open-std.org>; Mon, 16 Feb 2026 21:58:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1771275524;
	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:references:references;
	bh=1//B7KwSU1/MjiJx7/JAEOOyJ8Shau2cbxscQSYIuPw=;
	b=TjcvyAssC8H+7F20j5u1q6C/o7/OdMDJF74zklcqPpHgI36MuCyjZKbS4rVaX9/V4+4vC0
	rmqlPzXurEunRhF4/Afhm3oW3Zf6nqIFaFmG4P9OEgYhrRnfzseqTWg77yweiun26nYA3P
	8PBngvr9RAuNtNg5KY/AkLFPNBFyx6k=
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
 [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
 us-mta-141-A4xh-KurPWiKj0R_2RUWSQ-1; Mon, 16 Feb 2026 15:58:42 -0500
X-MC-Unique: A4xh-KurPWiKj0R_2RUWSQ-1
X-Mimecast-MFC-AGG-ID: A4xh-KurPWiKj0R_2RUWSQ_1771275521
Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48379489438so26366635e9.2
        for <sc22wg14@open-std.org>; Mon, 16 Feb 2026 12:58:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1771275521; x=1771880321;
        h=mime-version:references:message-id:in-reply-to:subject:cc:to:from
         :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1//B7KwSU1/MjiJx7/JAEOOyJ8Shau2cbxscQSYIuPw=;
        b=dLdgSfReritEdanBbQ1ve5d+HlnVjs0AjJHQB8WGZ67wB/RM5hEUyR6F9AshjNHjkf
         zggHiNQpMXL78yxUqV/Ik8uZ825rDiy1cGqDjK7TyDw15h9B33Oi2DDJc9lM8rp7UQY8
         M7T/yOxbTLq/B9dbEtaQd1ebKaeBkLazB7IQgt+sSbydWpbgGxu4QyVFb2fUCHEslw6Y
         Vw00EAqpQDCLg9yoNd5SrNxT0hSaDz/ZDhOXbPUST3YVA2arrEjzik9K6c/ubt7X0oU2
         Wvsy16lO5pRVv5NgU4vTz8dA9yuHi+8SLZ4gqTCOtvMTsY3+L5V5tdkM6xw8j580M/df
         8g8w==
X-Forwarded-Encrypted: i=1; AJvYcCVP5dDjX0NvjRlU9u9xdlDNAnV0nyM/e7nSDiAoE0tTtkOVFRjj5uTJXkvI2UjMP8lEdbGeJmSmuw==@open-std.org
X-Gm-Message-State: AOJu0YzCjIPIPl27ALOi6+O2du1jfprEluliXjB7W5azJ++Na+28NEct
	lr9WsRum0jsnR+NQQpSlvlBEpQH2h2cFT9B3+Lf1OENQi4rRve2ECBcAmnZeELpLBdhUCFfhxuG
	nDTUPTit8DzJCDZcSfZvXr5TXtMFoAc5q4WMA4kM6yi1fk9FGp5zD5dTW
X-Gm-Gg: AZuq6aKdXUYcPUrBuJ7FkXvyCgBkDzXJuFPYBDHPxPgagmsL+IYCtBOxLin1ynLUHey
	y1xtJGACPLoQ1W1hyah6ErduY11eISAdEp7vKU+bPENt9nxV6Jl6nFf+WveobMkVLlqOrN4ot3G
	ZFLBHGzw4Xu1isTjIcL07+jz2m4MGId9GnOY9GM5c20Z7M5D1TVK6uQBjSxSjqlObVWhT7ZS1tW
	3vqUqwe+wXvm7KqHp9+U5ygqcgJ1EKQKAkwOG8l8xsY3ljawjq+WxEsnDi+CYTUHRiiHqq7UiTs
	mBb4Ivfrej1fA0hdn+OqV/4mrlGTsbofqZqK+wpwDj1iHz1X/XKgmNXnhc5Qr7mbMPnmB+nD2LT
	t07WcOkmFjeymmtoJL+1a6d3fukVD0zCLtdlLlFF0kZ92tVd83ouH
X-Received: by 2002:a05:6000:2313:b0:437:664c:3f28 with SMTP id ffacd0b85a97d-43797926e60mr21702417f8f.47.1771275521425;
        Mon, 16 Feb 2026 12:58:41 -0800 (PST)
X-Received: by 2002:a05:6000:2313:b0:437:664c:3f28 with SMTP id ffacd0b85a97d-43797926e60mr21702398f8f.47.1771275520999;
        Mon, 16 Feb 2026 12:58:40 -0800 (PST)
Received: from digraph.polyomino.org.uk (digraph.polyomino.org.uk. [2001:8b0:bf73:93f7::51bb:e332])
        by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43796abe3b3sm34746291f8f.18.2026.02.16.12.58.40
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 16 Feb 2026 12:58:40 -0800 (PST)
Received: from jsm28 (helo=localhost)
	by digraph.polyomino.org.uk with local-esmtp (Exim 4.98.2)
	(envelope-from <josmyers@redhat.com>)
	id 1vs5fz-00000002bzD-3eou;
	Mon, 16 Feb 2026 20:58:39 +0000
Date: Mon, 16 Feb 2026 20:58:39 +0000 (UTC)
From: Joseph Myers <josmyers@redhat.com>
To: Alejandro Colomar <une+c@alejandro-colomar.es>
cc: Christopher Bazley <chris.bazley.wg14@gmail.com>, 
    Alex Celeste <alexg.nvfp@gmail.com>, sc22wg14 <sc22wg14@open-std.org>
Subject: Re: [SC22WG14.35384] alx-0088r0 - noreturn can't return
In-Reply-To: <20260214220545.7A903356A4E@www.open-std.org>
Message-ID: <cd12b85f-407f-ac30-d762-2ffa412a48b2@redhat.com>
References: <20260213083437.30B0A356D32@www.open-std.org> <CAEHU8x8MkCjzaPCkbbogsK1PFgAS0DuZoHkEXcatU4=5yE_xuw@mail.gmail.com> <20260214220545.7A903356A4E@www.open-std.org>
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-MFC-PROC-ID: c3JPBpDrDsWXh3IhYvVD11SNSj3JYCVwjLqWj1laD-Q_1771275521
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Sender: owner-sc22wg14@open-std.org
Precedence: bulk

On Sat, 14 Feb 2026, Alejandro Colomar wrote:

>     6.7.5  Function specifiers
> 	@@ Constraints, p5+1
> 	+A function declared with a <b>_Noreturn</b> function specifier
> 	+shall not contain a return statement.

What does "declared with" mean here?  It can't include a declaration in 
another translation unit.  What if the declaration with _Noreturn comes 
after the definition, or inside it, or is not in scope at the time of the 
definition because it was inside another function?

This is less of an issue with the noreturn attribute because of the rules 
"The first declaration of a function shall specify the noreturn attribute 
if any declaration of that function specifies the noreturn attribute. If a 
function is declared with the noreturn attribute in one translation unit 
and the same function is declared without the noreturn attribute in 
another translation unit, the behavior is undefined." (though those are 
all in Semantics, not Constraints, and don't actually make it entirely 
clear which cases would be covered by your proposed constraint on the 
attribute).

What isn't covered in the existing attribute wording is the case where the 
"first" declaration is inside a function and there are subsequent 
declarations or definition in the same translation unit without the 
attribute and without the prior declaration with the attribute being 
visible, and likewise when the prior declaration is shadowed when the 
function is redeclared without the attribute in block scope (but this last 
one is only relevant for declarations that aren't definitions).  Maybe 
this is a defect in the existing wording about that attribute.

-- 
Joseph S. Myers
josmyers@redhat.com

