On Wed, Apr 10, 2024 at 09:58:34AM +0000, Konstantin Ananyev 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. > > > > 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!
