Re: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations

[Alejandro Colomar <alx@kernel.org>]

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

Hi Martin,

> Date: 2026-09-14 20:34:07+0200
> From: Martin Uecker <uecker@tugraz.at>
>
> Am Montag, dem 14.09.2026 um 20:12 +0200 schrieb Alejandro Colomar:
> > 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);
> 
> The - rather serious in my opinion - issue with having a constraint
> is that you can not always control what identifiers are in
> scope, or will come into scope ten years later when some library
> you happen to use adds a new symbol and then now breaks your code.
> 
> Yes, for "n" this will not happen, for other symbols it might.
> The whole point of having scopes is that they shield the nested
> scopes from the outside.

I remember your concern.  But when I re-read the constraint today, I was
less concerned.  The thing is that the constraint is not triggered for
any clashes.  It's only triggered if all of the following happen:

	-  The identifier must be used in an array length expression.
	-  The identifier must be declared after the use in the array.

So, unless you're using retroactive declarations (which necessarily
needs this constraint, anyway), you shouldn't worry about the
constraint.  This code is fine:

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

> This becomes even more serious once you allow any kind of nested
> functions or lambdas, because then the collision surface becomes
> much larger.  If you insert lambdas via macros because people
> start to use them as a replacement for statement expressions, then
> you suddenly have macro that randomly fail to compile in
> specific contexts.

Still, as long as you don't use retroactive declarations in local
functions or function literals, you shouldn't worry.

> Maybe we should have both, forward declarations and some limited
> form of retroactive scoping.  Then one could fix collisions with
> a forward declaration that hides the outer symbol and harden
> macros.

Because of the above, I don't think this is needed.

I think forward declarations will still be useful in GCC, for example in
case you need --for some reason-- to specify a local function or a
function literal with an array declared before its length.  But this is
such a weird case that I think the standard could live without it.

> The issue that it would be a major pain to implement full
> retrospective scoping even in GCC remains.

Agree.  As a user, it seems great (given the constraints that make it
safe); as an implementor, it's a nightmare.

> I think the only
> realistic fix for this is to really narrow it down to a very
> limited set of expressions.
> 
> Martin


Have a lovely night!
Alex

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

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