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

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

[Petr Vorel]

request_key was left from GNU forward-declarations of parameters for
sizes of array parameters.

Fixes: d2c2db883 ("man/: SYNOPSIS: Use GNU forward-declarations of parameters for sizes of array parameters")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Hi Alejandro,

although I don't like N3207 GNU forward-declarations of parameters for
sizes of array parameters syntax (I'd prefer to have the signatures
which are in the headers) and I don't think it's practical (before one
could copy paste the signature from man page), I understand it's a
wanted feature. Therefore I fixed missing size parameter in request_key.

I suppose more functions were left in d2c2db883.

Kind regards,
Petr

 man/man2/request_key.2 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/man/man2/request_key.2 b/man/man2/request_key.2
index 3bb52f31b..d16642d9f 100644
--- a/man/man2/request_key.2
+++ b/man/man2/request_key.2
@@ -14,7 +14,8 @@ Linux Key Management Utilities
 .nf
 .B #include <keyutils.h>
 .P
-.BI "key_serial_t request_key(const char *" type ", const char *" description ,
+.BR "key_serial_t request_key(" "size_t size;"
+.BI "                         (const char *" type ", const char *" description ,
 .BI "                         const char *_Nullable " callout_info ,
 .BI "                         key_serial_t " dest_keyring );
 .fi
-- 
2.55.0

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

[Alejandro Colomar]

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

Hi Petr,

> Date: 2026-09-14 13:15:11+0200
> From: Petr Vorel <pvorel@suse.cz>
>
> request_key was left from GNU forward-declarations of parameters for
> sizes of array parameters.
> 
> Fixes: d2c2db883 ("man/: SYNOPSIS: Use GNU forward-declarations of parameters for sizes of array parameters")
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> Hi Alejandro,
> 
> although I don't like N3207 GNU forward-declarations of parameters for
> sizes of array parameters syntax (I'd prefer to have the signatures
> which are in the headers) and I don't think it's practical (before one
> could copy paste the signature from man page), I understand it's a
> wanted feature. Therefore I fixed missing size parameter in request_key.
> 
> I suppose more functions were left in d2c2db883.
> 
> Kind regards,
> Petr
> 
>  man/man2/request_key.2 | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/man/man2/request_key.2 b/man/man2/request_key.2
> index 3bb52f31b..d16642d9f 100644
> --- a/man/man2/request_key.2
> +++ b/man/man2/request_key.2
> @@ -14,7 +14,8 @@ Linux Key Management Utilities
>  .nf
>  .B #include <keyutils.h>
>  .P
> -.BI "key_serial_t request_key(const char *" type ", const char *" description ,
> +.BR "key_serial_t request_key(" "size_t size;"
> +.BI "                         (const char *" type ", const char *" description ,
>  .BI "                         const char *_Nullable " callout_info ,
>  .BI "                         key_serial_t " dest_keyring );

I don't see the 'size' being a parameter of this function at all.  Am
I missing something?


Have a lovely day!
Alex

>  .fi
> -- 
> 2.55.0
> 

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

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

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

[Petr Vorel]

Hi Alejandro,

> Hi Petr,

> > Date: 2026-09-14 13:15:11+0200
> > From: Petr Vorel <pvorel@suse.cz>

> > request_key was left from GNU forward-declarations of parameters for
> > sizes of array parameters.

> > Fixes: d2c2db883 ("man/: SYNOPSIS: Use GNU forward-declarations of parameters for sizes of array parameters")
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Hi Alejandro,

> > although I don't like N3207 GNU forward-declarations of parameters for
> > sizes of array parameters syntax (I'd prefer to have the signatures
> > which are in the headers) and I don't think it's practical (before one
> > could copy paste the signature from man page), I understand it's a
> > wanted feature. Therefore I fixed missing size parameter in request_key.

> > I suppose more functions were left in d2c2db883.

> > Kind regards,
> > Petr

> >  man/man2/request_key.2 | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)

> > diff --git a/man/man2/request_key.2 b/man/man2/request_key.2
> > index 3bb52f31b..d16642d9f 100644
> > --- a/man/man2/request_key.2
> > +++ b/man/man2/request_key.2
> > @@ -14,7 +14,8 @@ Linux Key Management Utilities
> >  .nf
> >  .B #include <keyutils.h>
> >  .P
> > -.BI "key_serial_t request_key(const char *" type ", const char *" description ,
> > +.BR "key_serial_t request_key(" "size_t size;"
> > +.BI "                         (const char *" type ", const char *" description ,
> >  .BI "                         const char *_Nullable " callout_info ,
> >  .BI "                         key_serial_t " dest_keyring );

> I don't see the 'size' being a parameter of this function at all.  Am
> I missing something?

Please drop this patch.  I'm sorry, I overlook that although request_key() has
const char *type like add_key(), unlike it it does not have size.

Anyway N3207 (spec mentioned in d2c2db883) is something I'll need to get used to :).

Kind regards,
Petr

> Have a lovely day!
> Alex

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

[Alejandro Colomar]

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

Hi Petr,

> Date: 2026-09-14 14:24:42+0200
> From: Petr Vorel <pvorel@suse.cz>
>
[..]
> Please drop this patch.  I'm sorry, I overlook that although request_key() has
> const char *type like add_key(), unlike it it does not have size.

Thanks!

> 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>

I've improved the GCC documentation, to discourage using several ';',
and added a diagnostic for it, which is in -Wextra:
'-Wmultiple-parameter-fwd-decl-lists'.
See the commit in gcc.git:
33c35b7f4c18 (2025-09-26; "c, objc: Add -Wmultiple-parameter-fwd-decl-lists")

The documentation for the GCC feature is at the bottom of this page:
<https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html>
It's easier to read than the standard specification, IMO.

> 
> Kind regards,
> Petr

Cheers,
Alex

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

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

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

[Mark Harris]

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>, and the
outcome from the last WG14 meeting was strong direction to proceed
along these lines.  Hopefully this much more human-readable approach
will prevail and we can do away with these confusing forward
declarations in parameter lists.

 - Mark

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

[Alejandro Colomar]

[-- 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 --]

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

[Martin Uecker]

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.

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.


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.

The issue that it would be a major pain to implement full
retrospective scoping even in GCC remains. I think the only
realistic fix for this is to really narrow it down to a very
limited set of expressions.

Martin

 


> 
> 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

status of C forward declarations (was: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations)

[G. Branden Robinson]

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

At 2026-09-14T10:19:13-0700, Mark Harris wrote:
> 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>, and the
> outcome from the last WG14 meeting was strong direction to proceed
> along these lines.  Hopefully this much more human-readable approach
> will prevail and we can do away with these confusing forward
> declarations in parameter lists.

This sort of naked triumphalism when reporting on working group
deliberations would be better replaced by a citation of the minutes of
the WG14 meeting in question.  Since you didn't do that, I will, and
further will quote the relevant portion.

At this point, the meeting minutes for summer 2026 are available in
draft form only.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3953.htm

---snip---
Na/, Forward Parameter References through Retroactive Scoping, v2
(Updates N3830) [N3923]

Celeste: I like this. But I am worried that "constraint" is too strong.
Unrelated libraries can collide with each other. I would recommended
practice be strong enough.

Bhakta: I like the changes. I also like that there is no new syntax for
it. Some compilers still have issues with far-enough look-ahead; that is
my only concern.

Gustedt: I am sympathetic to this approach; we need a solution. I am
still baffled that we did not get any other solutions. I am scared of
the complexity. I would still prefer forward declarations.

Celeste: This is similar for pre-C90 where you had to hook up with a
declaration later.

Adams: How does this integrate with the type system? Is it separated?

Na: Your question is about the attributes, right? This is not about
attributes. We have other proposals about intended attributes. What is
your proposal number?

Adams: My example is for the noreturn attribute. What is the current
status for the C type system?

Na: This proposal is for core language array size.

Bazley: SDCC already supports forward parameter declarations, but is
more limited than GCC. I wonder if this is an over-engineered solution
for a problem that does not need to exist at all?

Celeste: Is this ready for the Wording Group?

Gustedt: No, there are too many unanswered questions.

Columnar: I strongly prefer forward declarations. I like this proposal
more. Given that small implementors cannot implement this, I am not
comfortable accepting this.

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.

Na: I need to discuss with that person offline the nature of their
problem.

Colomar: Would it be acceptable for Clang to propose forward
declarations, and then allow compilers to decide whether they want to do
this retroactive parsing?

Tarditi: You could use that rationale to deny many changes. I do not
think this is a serious issue. We could add implementation-defined
limits if forward tokens is an issue.

Celeste: This could potentially be optional. I do not think that is
possible. It does not give any cues to the compiler. Which bits would be
optional? If the expression in the array bounds is limited to an
identifier, there is no parsing problem.

Meneide: We do have an "implementation limit" section in the standard
for such things. Limits on look-ahead for this feature can go there.

Straw Poll: Would WG14 like to adopt something along the lines of N3923
for C2y? 3-0-0+12-7-4=15-7-4 strong direction to proceed

Gustedt: If we want this into C2y, we should have a paper with the
semantics cleared by November, so it can go to the Wording Group.
---end snip---

I assume the "Columnar" listed above is a typo for "Colomar".

Regards,
Branden

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

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

[Alejandro Colomar]

[-- 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 --]

Re: status of C forward declarations (was: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations)

[Alejandro Colomar]

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

Hi Branden,

> Date: 2026-09-14 13:37:50-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
> At 2026-09-14T10:19:13-0700, Mark Harris wrote:
> > 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>, and the
> > outcome from the last WG14 meeting was strong direction to proceed
> > along these lines.  Hopefully this much more human-readable approach
> > will prevail and we can do away with these confusing forward
> > declarations in parameter lists.
> 
> This sort of naked triumphalism when reporting on working group
> deliberations would be better replaced by a citation of the minutes of
> the WG14 meeting in question.  Since you didn't do that, I will, and
> further will quote the relevant portion.
> 
> At this point, the meeting minutes for summer 2026 are available in
> draft form only.
> 
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3953.htm
> 
> ---snip---
> Na/, Forward Parameter References through Retroactive Scoping, v2
> (Updates N3830) [N3923]
> 
> Celeste: I like this. But I am worried that "constraint" is too strong.
> Unrelated libraries can collide with each other. I would recommended
> practice be strong enough.
> 
> Bhakta: I like the changes. I also like that there is no new syntax for
> it. Some compilers still have issues with far-enough look-ahead; that is
> my only concern.
> 
> Gustedt: I am sympathetic to this approach; we need a solution. I am
> still baffled that we did not get any other solutions. I am scared of
> the complexity. I would still prefer forward declarations.
> 
> Celeste: This is similar for pre-C90 where you had to hook up with a
> declaration later.
> 
> Adams: How does this integrate with the type system? Is it separated?
> 
> Na: Your question is about the attributes, right? This is not about
> attributes. We have other proposals about intended attributes. What is
> your proposal number?
> 
> Adams: My example is for the noreturn attribute. What is the current
> status for the C type system?
> 
> Na: This proposal is for core language array size.
> 
> Bazley: SDCC already supports forward parameter declarations, but is
> more limited than GCC. I wonder if this is an over-engineered solution
> for a problem that does not need to exist at all?
> 
> Celeste: Is this ready for the Wording Group?
> 
> Gustedt: No, there are too many unanswered questions.
> 
> Columnar: I strongly prefer forward declarations. I like this proposal
> more. Given that small implementors cannot implement this, I am not
> comfortable accepting this.

This lacks some context.  "I like this proposal more [compared to the
previous version of it]."

> 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.
> 
> Na: I need to discuss with that person offline the nature of their
> problem.
> 
> Colomar: Would it be acceptable for Clang to propose forward
> declarations, and then allow compilers to decide whether they want to do
> this retroactive parsing?
> 
> Tarditi: You could use that rationale to deny many changes. I do not
> think this is a serious issue. We could add implementation-defined
> limits if forward tokens is an issue.
> 
> Celeste: This could potentially be optional. I do not think that is
> possible. It does not give any cues to the compiler. Which bits would be
> optional? If the expression in the array bounds is limited to an
> identifier, there is no parsing problem.
> 
> Meneide: We do have an "implementation limit" section in the standard
> for such things. Limits on look-ahead for this feature can go there.
> 
> Straw Poll: Would WG14 like to adopt something along the lines of N3923
> for C2y? 3-0-0+12-7-4=15-7-4 strong direction to proceed
> 
> Gustedt: If we want this into C2y, we should have a paper with the
> semantics cleared by November, so it can go to the Wording Group.
> ---end snip---
> 
> I assume the "Columnar" listed above is a typo for "Colomar".

Yes, it is.


Have a lovely night!
Alex

> 
> Regards,
> Branden



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

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

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

[Martin Uecker]

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. 

> 
> > 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? 

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).

Martin

> 
> > 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

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

[Alejandro Colomar]

[-- 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 --]

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

[Martin Uecker]

Am Dienstag, dem 15.09.2026 um 11:02 +0200 schrieb Alejandro Colomar:
> 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 already understand that. I do not want

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

to be a constraint violation, because if I write

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

and any header that later puts an "n" into file scope somewhere, even
in a library maintained by somebody else, perhaps a decade after the
original code was written, this then may cause a surprising
compilation errors.  It is an action at a distance issue nobody
needs.


And the only reason why this may seem unlikely in this toy example
is that nobody would use a single letter "n" as a global variable, but
in real code not all parameters have such short names.

> 
> 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.

On a theoretical level I can understand your argument.  But in
reality this is a purely theoretical issue as nobody writes such 
code.  Even using a global variable as length is already extremely
rare, but then using the same name as parameter while intending
to use the original global variable would seem to make such code
so unlikely that I do not think it exists.

What is more common is to use a constant, e.g. a macro or
enumeration value.

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

But then again, it seems very unlikely that writes

enum { MAX_DIMS = 100 };

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

with the intention that the first MAX_DIMS actually
refers to the global variable and not to the parameter.
If such code exits, it is  almost certainly already an
unintentional error.


> 
> 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.

It would be positive (although largely irrelevant), if not for 
the action-at-a-distance issue above (which I do not think is
irrelevant).

> 
> > 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.

Forward declaration are not standardized, so people avoid them.

But the issue of name collision in local contexts is much more
serious.  This is exactly the reason people come up with sophisticated
macro contraptions to create unique names for temporaries in
macros, and why people ask for lambdas to have clean alternative
instead that does not have such fundamental problems.  Introducing
lambdas, but then breaking this in a way that it has the same issue
would be really a terrible idea. 

But, yes, this was my point: If we added that constraint, 
something like forward declarations could be used to avoid writing
fragile macros.

> 
> 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.

I do not think that breaking fundamental language features such as scoping,
and requiring everybody to prefix all their names to prevent collisions
is a viable.  Also a single prefix is not enough in nested macros, you
would need a unique identifier in each nested instance.

> 
> 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.

Simple not having the constraint would also be ok with me.

Martin

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

[Alejandro Colomar]

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

Hi Martin,

> Date: 2026-09-15 11:45:31+0200
> From: Martin Uecker <uecker@tugraz.at>
>
[...]
> > 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 already understand that. I do not want
> 
> int n;
> void i(int a[n], int n);
> 
> to be a constraint violation, because if I write
> 
> void i(int a[n], int n);
> 
> and any header that later puts an "n" into file scope somewhere, even
> in a library maintained by somebody else, perhaps a decade after the
> original code was written, this then may cause a surprising
> compilation errors.  It is an action at a distance issue nobody
> needs.
> 
> 
> And the only reason why this may seem unlikely in this toy example
> is that nobody would use a single letter "n" as a global variable, but
> in real code not all parameters have such short names.
> 
> > 
> > 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().
> > 
[...]
> > 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.
> 
> On a theoretical level I can understand your argument.  But in
> reality this is a purely theoretical issue as nobody writes such 
> code.  Even using a global variable as length is already extremely
> rare, but then using the same name as parameter while intending
> to use the original global variable would seem to make such code
> so unlikely that I do not think it exists.
> 
> What is more common is to use a constant, e.g. a macro or
> enumeration value.
> 
> void i(int a[MAX_DIMS], int n);
> 
> But then again, it seems very unlikely that writes
> 
> enum { MAX_DIMS = 100 };
> 
> void i(int a[MAX_DIMS], int MAX_DIMS);
> 
> with the intention that the first MAX_DIMS actually
> refers to the global variable and not to the parameter.
> If such code exits, it is  almost certainly already an
> unintentional error.

And you would not diagnose such an unintentional error?

I think this seems to trigger again the discussion about whether we want
constraints for things that should be diagnostics, but where the user
should be allowed to continue translation.

I guess I can live without the constraint, because QoI will result in
compilers diagnosing this anyway.  I expect GCC would add a new value
-Wshadow=retroactive-parameter or something like that to warn
specifically about this situation.

> > 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.
> 
> It would be positive (although largely irrelevant), if not for 
> the action-at-a-distance issue above (which I do not think is
> irrelevant).
> 
> > > 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.
> 
> Forward declaration are not standardized, so people avoid them.
> 
> But the issue of name collision in local contexts is much more
> serious.  This is exactly the reason people come up with sophisticated
> macro contraptions to create unique names for temporaries in
> macros, and why people ask for lambdas to have clean alternative
> instead that does not have such fundamental problems.  Introducing
> lambdas, but then breaking this in a way that it has the same issue
> would be really a terrible idea. 
> 
> But, yes, this was my point: If we added that constraint, 
> something like forward declarations could be used to avoid writing
> fragile macros.
> 
> > 
> > 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.
> 
> I do not think that breaking fundamental language features such as scoping,
> and requiring everybody to prefix all their names to prevent collisions
> is a viable.  Also a single prefix is not enough in nested macros, you
> would need a unique identifier in each nested instance.
> 
[...]
> 
> Simple not having the constraint would also be ok with me.

Agreed.


Cheers,
Alex

> 
> Martin
> 

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

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

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

[Martin Uecker]

Am Dienstag, dem 15.09.2026 um 11:59 +0200 schrieb Alejandro Colomar:
> Hi Martin,
> 
> > Date: 2026-09-15 11:45:31+0200
> > From: Martin Uecker <uecker@tugraz.at>
> > 
> [...]
> > > 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 already understand that. I do not want
> > 
> > int n;
> > void i(int a[n], int n);
> > 
> > to be a constraint violation, because if I write
> > 
> > void i(int a[n], int n);
> > 
> > and any header that later puts an "n" into file scope somewhere, even
> > in a library maintained by somebody else, perhaps a decade after the
> > original code was written, this then may cause a surprising
> > compilation errors.  It is an action at a distance issue nobody
> > needs.
> > 
> > 
> > And the only reason why this may seem unlikely in this toy example
> > is that nobody would use a single letter "n" as a global variable, but
> > in real code not all parameters have such short names.
> > 
> > > 
> > > 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().
> > > 
> [...]
> > > 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.
> > 
> > On a theoretical level I can understand your argument.  But in
> > reality this is a purely theoretical issue as nobody writes such 
> > code.  Even using a global variable as length is already extremely
> > rare, but then using the same name as parameter while intending
> > to use the original global variable would seem to make such code
> > so unlikely that I do not think it exists.
> > 
> > What is more common is to use a constant, e.g. a macro or
> > enumeration value.
> > 
> > void i(int a[MAX_DIMS], int n);
> > 
> > But then again, it seems very unlikely that writes
> > 
> > enum { MAX_DIMS = 100 };
> > 
> > void i(int a[MAX_DIMS], int MAX_DIMS);
> > 
> > with the intention that the first MAX_DIMS actually
> > refers to the global variable and not to the parameter.
> > If such code exits, it is  almost certainly already an
> > unintentional error.
> 
> And you would not diagnose such an unintentional error?

This would not be a new error, but an old one.
Nobody felt the need to diagnose this in the last four decades.
And after the change, it would not be an error, so there seems
even less reason to diagnose it.

> 
> I think this seems to trigger again the discussion about whether we want
> constraints for things that should be diagnostics, but where the user
> should be allowed to continue translation.
> 
> I guess I can live without the constraint, because QoI will result in
> compilers diagnosing this anyway.  I expect GCC would add a new value
> -Wshadow=retroactive-parameter or something like that to warn
> specifically about this situation.

QoI might result in diagnostic if it turns out to be a problem.

But if it were a real issue, we would have the diagnostic already.

Martin

> 
> > > 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.
> > 
> > It would be positive (although largely irrelevant), if not for 
> > the action-at-a-distance issue above (which I do not think is
> > irrelevant).
> > 
> > > > 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.
> > 
> > Forward declaration are not standardized, so people avoid them.
> > 
> > But the issue of name collision in local contexts is much more
> > serious.  This is exactly the reason people come up with sophisticated
> > macro contraptions to create unique names for temporaries in
> > macros, and why people ask for lambdas to have clean alternative
> > instead that does not have such fundamental problems.  Introducing
> > lambdas, but then breaking this in a way that it has the same issue
> > would be really a terrible idea. 
> > 
> > But, yes, this was my point: If we added that constraint, 
> > something like forward declarations could be used to avoid writing
> > fragile macros.
> > 
> > > 
> > > 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.
> > 
> > I do not think that breaking fundamental language features such as scoping,
> > and requiring everybody to prefix all their names to prevent collisions
> > is a viable.  Also a single prefix is not enough in nested macros, you
> > would need a unique identifier in each nested instance.
> > 
> [...]
> > 
> > Simple not having the constraint would also be ok with me.
> 
> Agreed.
> 
> 
> Cheers,
> Alex
> 
> > 
> > Martin
> > 

-- 
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging

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

[Alejandro Colomar]

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

Hi Martin,

> Date: 2026-09-15 12:28:31+0200
> From: Martin Uecker <uecker@tugraz.at>
>
[...]
> > > But then again, it seems very unlikely that writes
> > > 
> > > enum { MAX_DIMS = 100 };
> > > 
> > > void i(int a[MAX_DIMS], int MAX_DIMS);
> > > 
> > > with the intention that the first MAX_DIMS actually
> > > refers to the global variable and not to the parameter.
> > > If such code exits, it is  almost certainly already an
> > > unintentional error.
> > 
> > And you would not diagnose such an unintentional error?
> 
> This would not be a new error, but an old one.
> Nobody felt the need to diagnose this in the last four decades.
> And after the change, it would not be an error, so there seems
> even less reason to diagnose it.

If retroactive scoping is added but optional (to allow small compilers
to live without it), then it might become a problem.  Porting code using
it to compilers not supporting it might successfully compile, but have
different semantics.

[...]
> 
> QoI might result in diagnostic if it turns out to be a problem.

But I would be okay, since indeed QoI would come to save us.

> But if it were a real issue, we would have the diagnostic already.


Cheers,
Alex

> 
> Martin

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

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