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

[Alejandro Colomar <alx.manpages@gmail.com>]

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

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