Linux Manual Pages development
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: linux-man@vger.kernel.org
Subject: 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 13:37:50 -0500	[thread overview]
Message-ID: <20260914183750.cpvfbblgoegjlo2f@illithid> (raw)
In-Reply-To: <CAMdZqKFVE-1-LkBR+ei77rd4dwXXS2AG_nySx5ACi61whtxG1g@mail.gmail.com>

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

  parent reply	other threads:[~2026-09-14 18:38 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         ` G. Branden Robinson [this message]
2026-09-14 21:06           ` status of C forward declarations (was: [PATCH 1/1] man/man2/request_key.2: Add missing GNU size forward-declarations) 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=20260914183750.cpvfbblgoegjlo2f@illithid \
    --to=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