Re: Segments

On 16/01/2025 17:46, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 16/01/2025 13:35, Michael S wrote:

On Thu, 16 Jan 2025 12:36:45 +0100
David Brown <david.brown@hesbynett.no> wrote:
>

On 15/01/2025 21:59, Thomas Koenig wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Wed, 15 Jan 2025 18:00:34 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
  

 

As you can guess, in kernel drivers VLA are unwelcome.

>
I can imagine that they are - but I really don't understand why.  I've
never understood why people think there is something "dangerous" about
VLAs, or why they think using heap allocations is somehow "safer".

 VLA normally allocate on the stack.  Which at first glance look
great.  But once one realize how small are stacks in modern
systems (compared to whole memory), this no longer looks good.
Basically, to use VLA one needs rather small bound on maximal
size of array.

Sure.

Given such bound always allocating maximal
size is simpler.  Without _small_ bound on size heap is
safer, as it is desined to handle also big allocations.

You don't allocate anything in a VLA without knowing the bounds and being sure it is appropriate to put on the stack.  You don't allocate anything on the heap without knowing the bounds and being sure it is appropriate.  There's no fundamental difference - it's just the cut-off point that is different.
The stack on Linux is 10 MB by default, and 1 MB by default on Windows. That's a /lot/ if you are working with fairly small but non-constant sizes.  So if you are working with a selection of short-lived medium-sized bits of data - say, parts of strings for some formatting work - putting them on the stack is safe and can be significantly faster than using the heap.
Using VLAs (or the older but related technique, alloca) means you don't waste space.  Maybe you are working with file paths, and want to support up to 4096 characters per path - but in reality most paths are less than 100 characters.  With fixed size arrays, allocating 16 of these and initialising them will use up your entire level 1 cache - with VLAs, it will use only a tiny fraction.  These things can make a big difference to code that aims to be fast.
Fixed size arrays are certainly easier to analyse and are often a good choice, but VLA's definitely have their advantages in some situations, and they are perfectly safe and reliable if you use them appropriately and correctly.

 In the past I was a fan of VLA and stack allocation in general.
But I saw enough bug reports due to programs exceeding their
stack limits that I changed my view.
 

Other people might have bad uses of VLAs - it doesn't mean /you/ have to use them badly too!

I do not know about Windows, but IIUC in some period Linux limit
for kernel stack was something like 2 kB (single page shared
with some other per-process data structures).  I think it
was increased later, but even moderate size arrays are
unwelcame on kernel stack due to size limits.

If a kernel stack is that small (or you are working on an embedded system with very small stacks), then clearly you have to take that into account.  I've used them a couple of times in embedded systems with small stacks - obviously the size of the VLA was also small.  (On such systems, heap allocations are very much unwelcome - though not quite as unwelcome as overflowing the stack :-) )
Far and away my most common use of VLAs is, however, not variable length at all.  It's more like :
const int no_of_whatsits = 20;
const int size_of_whatsit = 4;

uint8_t whatsits_data[no_of_whatsits * size_of_whatsit];
Technically in C, that is a VLA because the size expression is not a constant expression according to the rules of the language.  But of course it is a size that is known at compile-time, and the compiler generates exactly the same code as if it was a constant expression.  It is equally amenable to analysis and testing.  (In C++, it is considered a normal array - C++ does not support VLAs, but is happy with code like that.)  With C23, these const variables can now be constexpr, and the array will then be a normal array and not a VLA - without that making the slightest difference to the actual generated code.

 

VMTs are, may
be, tolerable (I wonder what is current policy of Linux and BSD
kernels), but hardly desirable.

 IMO VMT-s are vastly superior to raw pointers, but to fully
get their advantages one would need better tools.  Also,
kernel needs to deal with variable size arrays embedded in
various data structures.  This is possible using pointers,
but current VMT-s are too weak for many such uses.