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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
To: 	Alejandro Colomar <alx.manpages@xxxxxxxxx>
CC: 	Ingo Schwarze <schwarze@xxxxxxx>, linux-man@xxxxxxxxxxxxxxx



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: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux