Re: Segments

On Wed, 22 Jan 2025 14:58:04 +0000, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Wed, 22 Jan 2025 1:30:47 +0000, George Neuner wrote:
>

On Fri, 17 Jan 2025 16:42:17 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:
>

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

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.

>
In general, that is a hard thing to know - there is no standard
way to enquire the size of the stack, how much you have already
used, how deep you are going to recurse, or how much stack
a function will use.

>
Not standard compliant for sure, but you certainly can approximate
stack use in C:  just store (as byte*) the address of a local in your
top level function, and check the (absolute value of) the difference
to the address of a local in the current function.

>
On a Linux machine, you can find the last envp[*] entry and subtract
SP from it.

>
I would discourage programmers from relying on that for any reason
whatsoever.   The aux vectors are pushed before the envp entries.

This brings into question what is "on" the stack ?? to be included
in the measurement of stack size.
Only user data ??
Data that is present when control arrives ??
Could <equivalent> CRT0 store SP at arrival ??
I think we have an illdefined measurement !!