From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man@vger.kernel.org
Subject: Re: status of C forward declarations (was: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations)
Date: Mon, 14 Sep 2026 23:06:58 +0200 [thread overview]
Message-ID: <aqhhc0GjnyG42d2L@devuan> (raw)
In-Reply-To: <20260914183750.cpvfbblgoegjlo2f@illithid>
[-- 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 --]
prev parent reply other threads:[~2026-09-14 21:07 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
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 [this message]
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=aqhhc0GjnyG42d2L@devuan \
--to=alx@kernel.org \
--cc=g.branden.robinson@gmail.com \
--cc=linux-man@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox