All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Mark Harris <mark.hsj@gmail.com>
Cc: Petr Vorel <pvorel@suse.cz>,
	linux-man@vger.kernel.org,  Martin Uecker <uecker@tugraz.at>,
	Yeoul Na <yeoul_na@apple.com>, John McCall <rjmccall@apple.com>
Subject: Re: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations
Date: Mon, 14 Sep 2026 20:12:17 +0200	[thread overview]
Message-ID: <aqg0173m_lx_UB4G@devuan> (raw)
In-Reply-To: <CAMdZqKFVE-1-LkBR+ei77rd4dwXXS2AG_nySx5ACi61whtxG1g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3105 bytes --]

Hi Mark,

> Date: 2026-09-14 10:19:13-0700
> From: Mark Harris <mark.hsj@gmail.com>
>
> Alejandro Colomar wrote:
> > > Anyway N3207 (spec mentioned in d2c2db883) is something I'll need to get used to :).
> >
> > There's a more recent paper with a slightly better spec (also compatible
> > with GCC): N3681.
> > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3681.pdf>
> 
> There is an even more recent paper addressing this subject, N3923
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3923.pdf>,

Indeed, there's that newer proposal.  It's a different one, though.

> and the
> outcome from the last WG14 meeting was strong direction to proceed
> along these lines.

The actual poll results are 15 in favour, 7 against, and 4 abstentions.
I wouldn't have called that "strong direction to proceed".  I know
that's what the minutes say, but I don't agree with how polls are taken
as strong direction.  7 votes against is quite vocal opposition.

Here's a summary of the room feelings:
The committee was more or less (including myself) saying "as a user, I'd
like it, but as an implementor, it'd probably be a nightmare; as long as
implementors are okay with it, we're fine".  There was a comment from
one implementor of a small C compiler which essentially said it was
un-implementable for them, which raised some concerns.  From the
minutes:

	Uecker:	The SlimCC developer and another compiler developer
		wrote in a discussion about general features that they
		are worried about parameters for active declaration
		scoping.  It is difficult for them to implement this.
		They would rather implement template C++ functions.

I suggested a way forward: first, write a proposal prohibiting the use
of parameter names in array length expressions that clash with variables
declared at an outer scope.  The wording would look like this (taken
from n3923 itself):

    6.7.7.4  Function declarators
	@@ p4+1
	+Within a parameter declaration list,
	+if an identifier used in a parameter’s array bound expression
	+refers to a name declared later in the same list,
	+no declaration of an identifier with the same name
	+shall be visible from an enclosing scope.

This would require that the following code results in a diagnostic:

	int n;
	void foo(int a[n], int n);

But it would allow the following code without diagnostics:

	int n;
	void bar(int n, int a[n]);
	void baz(int a[n]);

This is obviously a good constraint, since it disallows code that is
most likely already broken, and doesn't affect code that works fine.

Once that constraint is in place, we could add --as a second proposal--
retroactive declaration of parameters being optional (so that small
compilers can say they don't support it), but we'll be sure that code
will not misbehave on such compilers.

>  Hopefully this much more human-readable approach
> will prevail and we can do away with these confusing forward
> declarations in parameter lists.

Agree.


Have a lovely day!
Alex

> 
>  - Mark

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-09-14 18:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-14 11:15 [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations Petr Vorel
2026-09-14 11:44 ` Alejandro Colomar
2026-09-14 12:24   ` Petr Vorel
2026-09-14 13:30     ` Alejandro Colomar
2026-09-14 17:19       ` Mark Harris
2026-09-14 18:12         ` Alejandro Colomar [this message]
2026-09-14 18:34           ` Martin Uecker
2026-09-14 21:03             ` Alejandro Colomar
2026-09-15  6:08               ` Martin Uecker
2026-09-15  9:02                 ` Alejandro Colomar
2026-09-15  9:45                   ` Martin Uecker
2026-09-15  9:59                     ` Alejandro Colomar
2026-09-15 10:28                       ` Martin Uecker
2026-09-15 10:56                         ` Alejandro Colomar
2026-09-14 18:37         ` status of C forward declarations (was: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations) G. Branden Robinson
2026-09-14 21:06           ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aqg0173m_lx_UB4G@devuan \
    --to=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mark.hsj@gmail.com \
    --cc=pvorel@suse.cz \
    --cc=rjmccall@apple.com \
    --cc=uecker@tugraz.at \
    --cc=yeoul_na@apple.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.