Re: Segments

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

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.

Well, AFAICS VLA-s may get allocated on function entry.  In such
case caller have to check for allocation size, which spreads
allocation related code between caller and called function.
In case of 'malloc' one can simply check return value.  In fact,
in many programs simple wrapper that exits in case of allocation
failure is enough (if application can not do its work without
memory and there is no memory, then there is no point in continuing
execution).

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.

IME this is relatively rare case.  For formatting frequently a single
result buffer (possibly expanded when needed) with other pieces of
data added there gave me good performance.  Intermediate strings
appeared as return values of called functions.  Without reoganizing
code this does not respect stack discipline.  Once reorganized
I get best results without materializing intermediate strings.

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.

One case initialize only used part.  Or simply used uninitialized
arrays (that is what I do normally).  It rather hard to give
meaningful initialization in case where size of payload varies.

 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!

Well, for me typical cases is for work arrays where needed size
may vary widely.  Using 'malloc' is simpler is such use given
small stack limit.  With small stack limit VLA would be a
micro-optimization, not worth extra effort.

<snip>

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.

OK, that is useful case (but in spirt this is not VLA).

--
                              Waldek Hebisch