[0/4] RFC samples converting VLA to alloca

  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.

what's the disadvantage of VLA over alloca()?

* VLA generation is subtl/implicit, there do appear to be places where
  a VLA is being used where it perhaps was not intended but it is hard
  to spot. e.g. hotpath rte_mbuf *array[burst_size]; where burst_size
  is not a constant expression, e.g. unintended in other syntax positions
  that are not intuitive, see patchwork link.

  https://patchwork.dpdk.org/project/dpdk/patch/1699896038-28106-1-git-send-email-roretzla@linux.microsoft.com/

for the above reasons i'd recommend only converting to alloca() where
necessary (msvc has to compile it) and for the other instances leave
them as they are.

Tyler Retzlaff (4):
  latencystats: use alloca instead of vla trivial
  hash: use alloca instead of vla trivial
  vhost: use alloca instead of vla sizeof
  dispatcher: use alloca instead of vla multi dimensional

 lib/dispatcher/rte_dispatcher.c     | 6 +++---
 lib/hash/rte_thash.c                | 2 +-
 lib/latencystats/rte_latencystats.c | 2 +-
 lib/vhost/socket.c                  | 5 +++--
 4 files changed, 8 insertions(+), 7 deletions(-)
  

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.

> what's the disadvantage of VLA over alloca()?
> 
> * VLA generation is subtl/implicit, there do appear to be places where
>    a VLA is being used where it perhaps was not intended but it is hard
>    to spot. e.g. hotpath rte_mbuf *array[burst_size]; where burst_size
>    is not a constant expression, e.g. unintended in other syntax positions
>    that are not intuitive, see patchwork link.
> 
>    https://patchwork.dpdk.org/project/dpdk/patch/1699896038-28106-1-git-send-email-roretzla@linux.microsoft.com/
> 
> for the above reasons i'd recommend only converting to alloca() where
> necessary (msvc has to compile it) and for the other instances leave
> them as they are.
> 
> Tyler Retzlaff (4):
>    latencystats: use alloca instead of vla trivial
>    hash: use alloca instead of vla trivial
>    vhost: use alloca instead of vla sizeof
>    dispatcher: use alloca instead of vla multi dimensional
> 
>   lib/dispatcher/rte_dispatcher.c     | 6 +++---
>   lib/hash/rte_thash.c                | 2 +-
>   lib/latencystats/rte_latencystats.c | 2 +-
>   lib/vhost/socket.c                  | 5 +++--
>   4 files changed, 8 insertions(+), 7 deletions(-)
>
  

> From: Mattias Rönnblom [mailto:hofors@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.

> 
> > what's the disadvantage of VLA over alloca()?
> >
> > * VLA generation is subtl/implicit, there do appear to be places where
> >    a VLA is being used where it perhaps was not intended but it is
> hard
> >    to spot. e.g. hotpath rte_mbuf *array[burst_size]; where burst_size
> >    is not a constant expression, e.g. unintended in other syntax
> positions
> >    that are not intuitive, see patchwork link.
> >
> >    https://patchwork.dpdk.org/project/dpdk/patch/1699896038-28106-1-
> git-send-email-roretzla@linux.microsoft.com/
> >
> > for the above reasons i'd recommend only converting to alloca() where
> > necessary (msvc has to compile it) and for the other instances leave
> > them as they are.
> >
> > Tyler Retzlaff (4):
> >    latencystats: use alloca instead of vla trivial
> >    hash: use alloca instead of vla trivial
> >    vhost: use alloca instead of vla sizeof
> >    dispatcher: use alloca instead of vla multi dimensional
> >
> >   lib/dispatcher/rte_dispatcher.c     | 6 +++---
> >   lib/hash/rte_thash.c                | 2 +-
> >   lib/latencystats/rte_latencystats.c | 2 +-
> >   lib/vhost/socket.c                  | 5 +++--
> >   4 files changed, 8 insertions(+), 7 deletions(-)
> >
  

On Sun, 7 Apr 2024 13:07:06 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > From: Mattias Rönnblom [mailto:hofors@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.
  

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 <mb@smartsharesystems.com> wrote:
> 
> > > From: Mattias Rönnblom [mailto:hofors@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.
* there is resistance to using alloca() vs VLA so my proposal is to
  change only the code that is built to target windows.
  

> From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
> >
> > > > From: Mattias Rönnblom [mailto:hofors@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.
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!

> * 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.
  

> > From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
> > >
> > > > > From: Mattias Rönnblom [mailto:hofors@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.
> 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!

Ok, but why we have to rush into 'alloca()' solution if none of us really fond of it?
As you already noted majority of these cases can be replaced with static sized arrays.
Let's try to compile a list of what needs to be changed, split it by priorities and work
progressively through it. 
Konstantin 

> 
> > * 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.
  

On Tue, Apr 09, 2024 at 08:28:48AM +0000, Konstantin Ananyev wrote:
> 
> 
> > > From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
> > > >
> > > > > > From: Mattias Rönnblom [mailto:hofors@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.
> > 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!
> 
> Ok, but why we have to rush into 'alloca()' solution if none of us really fond of it?

for the trivial case it is no worse than a VLA. while it isn't
standardized it is available for all platform/toolchains unlike VLA.
most of the code needed to be changed for windows falls into the trivial
case when converted.

there do appear to be cases where VLAs have just been unintentional.
i previously linked a patch where i fixed a case where they were
instantiated inside a cast and there are other cases i'm aware of in the
mlx5 driver where i believe they are unintended. at least with alloca
it is obvious but with a VLA if the expression used to determine the
size is wrapped up in something non-trivial and the author doesn't check
that it is truly a constant expression you get one by surprise.

> As you already noted majority of these cases can be replaced with static sized arrays.

unfortunately i don't think this is the case if we are talking about the
entire source tree.

> Let's try to compile a list of what needs to be changed, split it by priorities and work
> progressively through it.

i agree that working progressively is the way forward, my suggestion
partitioning has been to submit a smaller series that unblocks windows
using alloca as a starting point. this represents only a fraction of the
uses but can also serve for evaluation purposes.

if maintainers can identify a reasonable conversion to static array for
any of the converted instances i can incorporate the prescribed changes.

i would also suggest that in parallel we might introduce a series that
enables -Wvla but suppresses warning about -Wvla at the sites of use.
the purpose of this suggestion is to stop new introductions but also
annotate the uses we would like maintainers to evaluate. perhaps some
could also be trivially eliminated with the series.

> Konstantin 
> 
> > 
> > > * 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.
  

On 2024-04-08 17:27, Tyler Retzlaff wrote:
> 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 <mb@smartsharesystems.com> wrote:
>>
>>>> From: Mattias Rönnblom [mailto:hofors@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).

This is due to dogmatism, or what? Surely, a lot of Open Source projects 
written for C99 will use VLAs.

> * alloca() is an alternative that is available on all platforms/toolchain
>    combinations.

alloca() is a poor alternative. The use of alloca() should be restricted 
to situations where statically sized arrays can't do the job.

> * 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.
> * there is resistance to using alloca() vs VLA so my proposal is to
>    change only the code that is built to target windows.
  

On 2024-04-08 17:53, Morten Brørup wrote:
>> From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
>>>
>>>>> From: Mattias Rönnblom [mailto:hofors@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.
>
  

> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se]
> Sent: Wednesday, 10 April 2024 09.32
> 
> On 2024-04-08 17:53, Morten Brørup wrote:
> >> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> >> Sent: Monday, 8 April 2024 17.27
> >>

[...]

> >> 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 reasons against VLAs are the same as why MSVC doesn’t support them; primarily that they are insecure.

The reasons against VLAs and alloca() are the same, except MSVC supports 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.

It means that not enough people contribute to discussing and implementing alternatives, so we have to use the 1:1 replacement alternative, alloca(), to avoid stalling DPDK support for MSVC.

We can discuss and implement alternatives at any time, if anybody cares.

> 
> >> * 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.
> >
  

> >
> > > > From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
> > > > >
> > > > > > > From: Mattias Rönnblom [mailto:hofors@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.
> > > 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!
> >
> > Ok, but why we have to rush into 'alloca()' solution if none of us really fond of it?
> 
> for the trivial case it is no worse than a VLA. while it isn't
> standardized it is available for all platform/toolchains unlike VLA.
> most of the code needed to be changed for windows falls into the trivial
> case when converted.

Personally, I think VLA is much more convenient then alloca().
At least you can do sizeof(vla_array) without a problem.

> 
> there do appear to be cases where VLAs have just been unintentional.
> i previously linked a patch where i fixed a case where they were
> instantiated inside a cast and there are other cases i'm aware of in the
> mlx5 driver where i believe they are unintended. at least with alloca
> it is obvious but with a VLA if the expression used to determine the
> size is wrapped up in something non-trivial and the author doesn't check
> that it is truly a constant expression you get one by surprise.
> 
> > As you already noted majority of these cases can be replaced with static sized arrays.
> 
> unfortunately i don't think this is the case if we are talking about the
> entire source tree.

Ok, probably I misunderstood this RFC intention:
My first thought that it was all you need to make some minimalistic DPDK build with MSVC.
If that's not the case, then what would be the full list of changes that are necessary? 
 
> > Let's try to compile a list of what needs to be changed, split it by priorities and work
> > progressively through it.
> 
> i agree that working progressively is the way forward, my suggestion
> partitioning has been to submit a smaller series that unblocks windows
> using alloca as a starting point. this represents only a fraction of the
> uses but can also serve for evaluation purposes.

My concern here is that we are replacing something that is probably not ideal with
something that is even worse.
I do understand that it supposed to be a temporary measure, but as you said
alloca() is supported nearly everywhere, so in theory there would be no strong
reason for maintainers to spend their time on further code rearrangements to replace
alloca() with static arrays.  

> 
> if maintainers can identify a reasonable conversion to static array for
> any of the converted instances i can incorporate the prescribed changes.

Ok, that's why I suggested to start with the list of required changes.
And then decide on component-by-component basis.
From my side, I am ok to spend some time on the libs I am responsible for,
to do such code changes.

> i would also suggest that in parallel we might introduce a series that
> enables -Wvla but suppresses warning about -Wvla at the sites of use.
> the purpose of this suggestion is to stop new introductions but also
> annotate the uses we would like maintainers to evaluate. perhaps some
> could also be trivially eliminated with the series.
> 
> > Konstantin
> >
> > >
> > > > * 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.
  

On Wed, Apr 10, 2024 at 09:58:34AM +0000, Konstantin Ananyev wrote:
> 
> 
> > >
> > > > > From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
> > > > > >
> > > > > > > > From: Mattias Rönnblom [mailto:hofors@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.
> > > > 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!
> > >
> > > Ok, but why we have to rush into 'alloca()' solution if none of us really fond of it?
> > 
> > for the trivial case it is no worse than a VLA. while it isn't
> > standardized it is available for all platform/toolchains unlike VLA.
> > most of the code needed to be changed for windows falls into the trivial
> > case when converted.
> 
> Personally, I think VLA is much more convenient then alloca().
> At least you can do sizeof(vla_array) without a problem.
> 
> > 
> > there do appear to be cases where VLAs have just been unintentional.
> > i previously linked a patch where i fixed a case where they were
> > instantiated inside a cast and there are other cases i'm aware of in the
> > mlx5 driver where i believe they are unintended. at least with alloca
> > it is obvious but with a VLA if the expression used to determine the
> > size is wrapped up in something non-trivial and the author doesn't check
> > that it is truly a constant expression you get one by surprise.
> > 
> > > As you already noted majority of these cases can be replaced with static sized arrays.
> > 
> > unfortunately i don't think this is the case if we are talking about the
> > entire source tree.
> 
> Ok, probably I misunderstood this RFC intention:
> My first thought that it was all you need to make some minimalistic DPDK build with MSVC.
> If that's not the case, then what would be the full list of changes that are necessary? 

just to clarify expectations around scope.

MSVC is intended to be the primary toolchain for DPDK on Windows so the
scope of what is covered is any drivers or libraries that build for
Windows.

clang build for Windows is being maintained at high priority but lacks
capabilities Windows users require.

> > > Let's try to compile a list of what needs to be changed, split it by priorities and work
> > > progressively through it.
> > 
> > i agree that working progressively is the way forward, my suggestion
> > partitioning has been to submit a smaller series that unblocks windows
> > using alloca as a starting point. this represents only a fraction of the
> > uses but can also serve for evaluation purposes.
> 
> My concern here is that we are replacing something that is probably not ideal with
> something that is even worse.
> I do understand that it supposed to be a temporary measure, but as you said
> alloca() is supported nearly everywhere, so in theory there would be no strong
> reason for maintainers to spend their time on further code rearrangements to replace
> alloca() with static arrays.  
> 
> > 
> > if maintainers can identify a reasonable conversion to static array for
> > any of the converted instances i can incorporate the prescribed changes.
> 
> Ok, that's why I suggested to start with the list of required changes.
> And then decide on component-by-component basis.

The list is what is produced with -Wvla enabled on a clang build
targeting Windows.

> >From my side, I am ok to spend some time on the libs I am responsible for,
> to do such code changes.

I appreciate it!
  

On Wed, Apr 10, 2024 at 09:32:10AM +0200, Mattias Rönnblom wrote:
> On 2024-04-08 17:53, Morten Brørup wrote:
> >>From: Tyler Retzlaff [mailto:roretzla@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 <mb@smartsharesystems.com> wrote:
> >>>
> >>>>>From: Mattias Rönnblom [mailto:hofors@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().

truncated the sentence, probably should have said where static array is
not practical.
  

On Wed, Apr 10, 2024 at 09:27:10AM +0200, Mattias Rönnblom wrote:
> On 2024-04-08 17:27, Tyler Retzlaff wrote:
> >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 <mb@smartsharesystems.com> wrote:
> >>
> >>>>From: Mattias Rönnblom [mailto:hofors@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).
> 
> This is due to dogmatism, or what? Surely, a lot of Open Source
> projects written for C99 will use VLAs.

well the statement from the MSVC team was

  "VLAs provide attack vectors comparable to those of the infamous
   gets() — deprecated and destined to removal — for opportunities of
   “shifting the stack” and other exploits.
   For these reasons we intend not to support VLAs as an optional
   feature in C11"

i'm only communicating that they will neve be supported not debating the
reasons why. it's simply a statement in fact.

> 
> >* alloca() is an alternative that is available on all platforms/toolchain
> >   combinations.
> 
> alloca() is a poor alternative. The use of alloca() should be
> restricted to situations where statically sized arrays can't do the
> job.

agree comletely.