SoylentNews is people
SoylentNews
from the constants-aren't-variables-won't dept.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA:
VLAs [(Varable Length Arrays)] allow for array lengths to be determined at run-time rather than compile time. The Linux kernel has long relied upon VLAs in different parts of the kernel -- including within structures -- but going on for months now (and years if counting the kernel Clang'ing efforts) has been to remove the usage of variable-length arrays within the kernel. The problems with them are:
- Using variable-length arrays can add some minor run-time overhead to the code due to needing to determine the size of the array at run-time.
- VLAs within structures is not supported by the LLVM Clang compiler and thus an issue for those wanting to build the kernel outside of GCC, Clang only supports the C99-style VLAs.
- Arguably most importantly is there can be security implications from VLAs around the kernel's stack usage.
[...] Kees Cook[*] sent out the pull request today for VLA removal that now enables the "-Wvla" compiler flag to emit a warning should any variable-length array be found within the kernel's C code. That will help prevent new code from inadvertently using VLAs and also spot any lingering kernel code still relying upon this behavior.
Kees Cook wrote that there still might be a few places where VLAs could be found, "there may be a couple more VLAs hiding in hard-to-find randconfigs, but nothing big has shaken out in the last month or so in linux-next. We should be basically VLA-free now! Wheee. :)"
[*] KeesCook.
Have you ever used VLAs? Removed them? Why?
(Score: 3, Interesting) by bzipitidoo on Monday October 29 2018, @03:34PM
One of the biggest lacks in Fortran 77 is any sort of dynamic memory allocation. Instead, what the programmer has to do is calculate the maximum possible size for every data structure, to know what sizes to declare the arrays.
For example, if you use a queue to do a flood fill sort of operation in Fortran 77, you'd have to run the numbers. You could keep it simple and waste some memory, for instance by observing that the queue could never grow larger than the number of pixels in the image, so if the maximum image size is nxn, then declaring the array for the queue to be size n^2 would work. Or you could get more sophisticated and try to figure the worst case queue size. And here you could get too aggressive, and go for 4n, on the thought that the length of the perimeter of the flood fill can never exceed the length of the perimeter of the image. Unfortunately, if you did that, you'd be wrong. However it would probably work for most images, and the bug might go undetected for quite some time before someone hands it an image that needs more than 4n memory. A safe figure is 0.5*n^2, but still isn't as small as it could be. Using dynamic allocation is a great way to punt on those sorts of questions, just have the computer allocate memory as needed, and if the operation uses less than 4n elements in the queue, great, and if it uses more, it'll still work. But then, dynamic allocation has more overhead and is slower, there's no avoiding that.
You could try to find the maximum queue size experimentally. Write a dynamic memory allocation version, give it a bunch of test images that includes the worst cases you can imagine, and track the maximum queue size, then use that plus maybe a bit extra, as your array size for the static memory version. Of course, if you didn't think of the very worst case, and didn't allocate enough, then the code is bugged. And besides, that's a lot of work that may well not be worth the trouble, just allocate 0.5*n^2 and be done with it. Another hack that is frequently done in Fortran is using the same big array for several different structures, knowing that they will not be used at the same time. Even make the array global. But if you do that, then the program is much more painful to parallelize, should that be wanted later.
A hybrid approach is viable. Don't screw around with dynamic allocation for piddling amounts of memory, none of this allocation of one element at a time, go for chunks of 256 bytes or 1K or some such. Though again, it all depends on what is being done. How critical is that code to the overall performance, is it worth going to a lot of effort to optimize? One would suppose that for the kernel, it often is worth some effort to find smaller maximums, save a few bytes and a few cycles.