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: 7821 bytes --]

Hi Martin,

> Date: 2026-09-15 08:08:24+0200
> From: Martin Uecker <uecker@tugraz.at>
>
> Am Montag, dem 14.09.2026 um 23:03 +0200 schrieb Alejandro Colomar:
> > 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,
> 
> ..
> 
> > > > 
> > > > 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]);
> 
> I don't see why you need the constraint.  You can just change
> scoping rules so that the inner "n" shadows the outside, making
> the code work as intended.
> 
> > > 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.
> 
> I don't see how you come to this conclusion, I think it is
> an issue even at file scope. 

Let's quote the text of the constraint, and I'll numerate the lines:

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

Let's write a translation unit:

	// foo.c

	int n;  // global 'n'

	void f(int n);  // fine, doesn't trigger line 2; it shadows

	void g(int n, int a[n]);  // fine, doesn't trigger line 3; it shadows

	void h(int a[n]);  // fine, doesn't trigger line 3; uses global 'n'

	void i(int a[n], int n);  // Constraint violation

	void j(int n; int a[n], int n);  // Constraint violation, but see below

Does it make sense now?

I would relax the constraint for case j(), since it's clearly okay.
Since forward declarations are non-standard, we can't have the standard
wording say something about forward declarations, but as QoI, I'd not
trigger the diagnostic for j().

> > > 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.
> 
> Is your argument that people simply will not use retrospective scoping
> for new code anyway, so it is not a practical problem? 

My arguments is that currently, the following code has a meaning:

	int n;

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

If we add retroactive scoping, the semantics of that code would change.
(Add 'static' if you care about ISO C not respecting [n].)
Thus, functions using retroactive scoping need to prohibit this code,
to avoid silent changes.

As long as the constraint affects only functions using retroactive
scoping and functions that we agree are currently bad (because they look
like retroactive scoping, but they aren't), the constraint seems
positive.

> I am not sure about this, I have seen WG14 add new functions with
> the size later because people insisted it is more ideomatic (despite
> the charter saying this should not be done).

And I still do it for new str*() and mem*() functions, because, indeed,
it is more idiomatic/consistent with related APIs.

But that's a conscious decision.  If you add such a function, then you
either use GNU C's forward declarations to avoid the constraint, or you
use a parameter name that you know won't be used elsewhere.

libc has it easy: a name reserved in the global namespace (__n) would
work.  It only needs to be self consistent, and not declare __n
globally.  Other libraries will have to prefix the parameters with the
library prefix, I guess.

If you add a local/literal function, then you need to be more careful
with the parameter name.  Or just don't use retroactive scoping.  It's
a conscious decision.  In GNU C, we have the tools available.

I would love to see forward declarations standardized so that everyone
can use them to avoid this constraint in the simplest way.  They are
compatible with retroactive scoping, so we could see both standardized.
But that's orthogonal.


Cheers,
Alex

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

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