Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Alejandro Colomar
2022-09-02T21:02:21Z

[-- Attachment #1.1: Type: text/plain, Size: 3856 bytes --]

Hi JeanHeyd!

I'm forwarding your email to the mailing list, from my post-1996 mail
client ;)

I hope all of your content is kept (even if slightly degraded).

Cheers,

Alex

-------- Forwarded Message --------
Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in
function parameters
Date: Fri, 2 Sep 2022 16:56:00 -0400
From: JeanHeyd Meneide <wg14@soasis.org>
To: Alejandro Colomar <alx.manpages@gmail.com>
CC: Ingo Schwarze <schwarze@usta.de>, linux-man@vger.kernel.org

Hi Alejandro and Ingo,

Just chiming in from a Standards perspective, here. We discussed,
briefly, a way to allow Variable-Length function parameter declarations
like the ones shown in this thread (e.g., char *getcwd(char buf[size],
size_t size );).

In GCC, there is a GNU extension that allows explicitly
forward-declaring the prototype. Using the above example, it would look
like so:

char *getcwd(size_t size; char buf[size], size_t size);

(Live Example [1])

(Note the `;` after the first "size" declaration). This was brought
before the Committee to vote on for C23 in the form of N2780 [2], around
the January 2022 timeframe. The paper did not pass, and it was seen as a
"failed extension". After the vote on that failed, we talked about other
ways of allowing places whether there was some appetite to allow
"forward parsing" for this sort of case. That is, could we simply allow:

char *getcwd(char buf[size], size_t size);

to work as expected. The vote for this did not gain full consensus
either, but there were a lot of abstentions [3]. While I personally
voted in favor of allowing such for C, there was distinct worry that
this would produce issues for weaker C implementations that did not want
to commit to delayed parsing or forward parsing of the entirety of the
argument list before resolving types. There are enough abstentions
during voting that a working implementation with a writeup of complexity
would sway the Committee one way or the other.

This is not to dissuade Alejandro's position, or to bolster Ingo's
point; I'm mostly just reporting the Committee's response here. This is
an unsolved problem for the Committee, and also a larger holdover from
the removal of K&R declarations from C23, which COULD solve this problem:

// decl
char *getcwd();

// impl
char* getcwd(buf, size)
char buf[size];
size_t size;
{
/* impl here */
}

There is room for innovation here, or perhaps bolstering of the
GCC original extension. As it stands right now, compilers only very
recently started taking Variably-Modified Type parameters and Static
Extent parameters seriously after carefully separating them out of
Variable-Length Arrays, warning where they can when static or other
array parameters do not match buffer lengths and so-on.

Not just to the folks in this thread, but to the broader
community for anyone who is paying attention: WG14 would actively like
to solve this problem. If someone can:
- prove out a way to do delayed parsing that is not implementation-costly,
- revive the considered-dead GCC extension, or
- provide a 3rd or 4th way to support the goals,

I am certain WG14 would look favorably upon such a thing eventually,
brought before the Committee in inclusion for C2y/C3a.

Whether or not you feel like the manpages are the best place to
start that, I'll leave up to you!

Thanks,
JeanHeyd

[1]: https://godbolt.org/z/dv1G3qGa3 <https://godbolt.org/z/dv1G3qGa3>
[2]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2780.pdf
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2780.pdf>
[3]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2991.pdf
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2991.pdf> - search
for n2780