RE: RFC acceptable handling of VLAs across toolchains

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Wednesday, 8 November 2023 04.25
> 
> On Tue, Nov 07, 2023 at 06:31:14PM -0800, Stephen Hemminger wrote:
> > On Tue, 7 Nov 2023 11:32:20 -0800
> > Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
> >
> > > hi folks,
> > >
> > > i'm seeking advice. we have use of VLAs which are now optional in
> > > standard C. some toolchains provide a conformant implementation and
> msvc
> > > does not (and never will).

Just so everyone is on the same page... this is a VLA (Variable Length Array):

void f(int n) {
  int v[n]; // VLA: its size is determined at run-time.
}

> > >
> > > we seem to have a few options, just curious about what people would
> > > prefer.
> > >
> > > * use alloca

VLAs have the advantage that they are allocated on the stack, which usually means that the memory is already present in the CPU's L1 cache (or L2 cache if using a larger block of memory).
It seems alloca() also allocates on the stack, so alloca() should provide similar performance.

> > >
> > > * use dynamically allocated storage

This would probably have lower performance than alloca() due to using "cold" memory, as opposed to memory on the stack.

And it needs to be explicitly freed again, which is somewhat annoying, compared to automatically freed memory.

> > >
> > > * conditional compiled code where the msvc leg uses one of the
> previous
> > >   two options

I agree with Stephen on this: Whatever VLA alternative we choose for MSVC, other compilers can use that too. There is no need for #ifdefs to keep VLAs for other compilers.

> > >
> > > i'll leave it simple for now, i'd like to hear input rather than
> provide
> > > a recommendation for now.
> > >
> >
> > VLAs are a bug magnet. Best to avoid them, most code doesn't need
> them.
> 
> just in case i didn't clarify properly early when i said they were
> optional i meant they used to be non-optional.

VLAs were standard in C99, and became optional in C11.

> the intent of the RFC
> here isn't that i want to add more but i'm looking for the best
> approach
> to getting rid of the ones we already have.
> > The one common use case is code that accepts a burst of packets.
> > But such code could easily have an upper bound if necessary.

Exactly!

I suggest that we forbid the use of VLAs.

For fast path code, constant-size arrays should be strongly recommended.

For non-fast path code, use alloca() or whatever VLA alternative is convenient on a case-by-case basis.

Perhaps checkpatches can detect the use of VLAs? Or it could be updated to check for them.


For reference, VLAs are forbidden in the Linux Kernel [1]. A good excuse for also forbidding them in DPDK. ;-)

[1]: https://www.phoronix.com/news/Linux-Kills-The-VLA


> >
> > Please don't add more to the maze of #ifdef's
> 
> thanks! i'll keep this in mind.