On 2024-04-08 17:53, Morten Brørup wrote:
From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
Sent: Monday, 8 April 2024 17.27
For next technboard meeting.
On Sun, Apr 07, 2024 at 10:03:06AM -0700, Stephen Hemminger wrote:
On Sun, 7 Apr 2024 13:07:06 +0200
Morten Brørup <m...@smartsharesystems.com> wrote:
From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
Sent: Sunday, 7 April 2024 11.32
On 2024-04-04 19:15, Tyler Retzlaff wrote:
This series is not intended for merge. It insteat provides examples
of
converting use of VLAs to alloca() would look like.
what's the advantages of VLA over alloca()?
* sizeof(array) works as expected.
* multi-dimensional arrays are still arrays instead of pointers to
dynamically allocated space. this means multiple subscript syntax
works (unlike on a pointer) and calculation of addresses into
allocated
space in ascending order is performed by the compiler instead of
manually.
alloca() is a pretty obscure mechanism, and also not a part of the C
standard. VLAs are C99, and well-known and understood, and very
efficient.
The RFC fails to mention why we need to replace VLAs with something else:
VLAs are C99, but not C++; VLAs were made optional in C11.
MSVC doesn't support VLAs, and is not going to:
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-
arriving-in-msvc/#variable-length-arrays
I dislike alloca() too, and the notes section in the alloca(3) man page
even discourages the use of alloca():
https://man7.org/linux/man-pages/man3/alloca.3.html
But I guess alloca() is the simplest replacement for VLAs.
This RFC patch series opens the discussion for alternatives in different
use cases.
The other issue with VLA's is that if the number is something that can be
externally
input, then it can be a source of stack overflow bugs. That is why the Linux
kernel
has stopped using them; for security reasons. DPDK has much less of a
security
trust domain. Mostly need to make sure that no data from network is being
used to compute VLA size.
Looks like we need to discuss this at the next techboard meeting.
* MSVC doesn't support C11 optional VLAs (and never will).
* alloca() is an alternative that is available on all platforms/toolchain
combinations.
* it's reasonable for some VLAs to be turned into regular arrays but it
would be unsatisfactory to be stuck waiting discussions of defining new
constant expression macros on a per-use basis.
We must generally stop using VLAs, for many reasons.
What reasons would that be? And which of those reasons are not also
reasons to stop using alloca().
The only available 1:1 replacement is alloca(), so we have to accept that.
If anyone still cares about improvements, we can turn alloca()'d arrays into
regular arrays after this patch series.
Alternatives to VLAs are very interesting discussions, but let's not stall MSVC
progress because of it!
What is this supposed to mean? Finding alternatives to VLAs are required
to make progress of MSVC support in DPDK.
* there is resistance to using alloca() vs VLA so my proposal is to
change only the code that is built to target windows.
I would prefer to get rid of them all, so the CI can build with -Wvla to
prevent them from being introduced again.
Not a strong preference.
On the other hand, the CI's MSVC builds will catch them if used for a Windows
target.
And limiting to Windows code reduces the amount of work, so that's probably the
most realistic solution.
