Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Segments
Date: Fri, 17 Jan 2025 18:21:26 +0100
Organization: A noiseless patient Spider
Lines: 93
Message-ID: <vme3im$4pii$1@dont-email.me>
References: <vdlgl9$3kq50$2@dont-email.me> <vlgreu$1lsr9$1@dont-email.me>
 <vlhjtm$1qrs5$1@dont-email.me> <bdZeP.23664$Hfb1.16566@fx46.iad>
 <vlj1pg$25p0e$1@dont-email.me> <87cygo97dl.fsf@nosuchdomain.example.com>
 <vm7mvi$2rr87$1@dont-email.me> <20250115140026.00003f4f@yahoo.com>
 <vm8t42$3221i$1@dont-email.me> <20250115222824.000034d6@yahoo.com>
 <vm97j3$342b3$1@dont-email.me> <vmar0d$3g078$1@dont-email.me>
 <20250116143532.00002117@yahoo.com> <vmavsb$3gpni$1@dont-email.me>
 <vmbd4n$3v6su$3@paganini.bofh.team> <vmbsvr$3lpar$1@dont-email.me>
 <vme199$4g29$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 17 Jan 2025 18:21:27 +0100 (CET)
Injection-Info: dont-email.me; posting-host="eac6ea3806850550cb7a14bb1d188128";
	logging-data="157266"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19FjG2mnCTfRzmjNFIseDSXOZP4wJhi574="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:jCtfWWYkUJeTP/U25vyk+5xRhsI=
Content-Language: en-GB
In-Reply-To: <vme199$4g29$1@dont-email.me>
Bytes: 5729

On 17/01/2025 17:42, Thomas Koenig 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.
> 

That would be another way of saying you have no idea when your program 
is going to blow up from lack of stack space.  You don't need VLAs to 
cause such problems.

In reality, you /do/ know a fair amount.  Often your knowledge is 
approximate - you know you are not going to need anything like as much 
stack as the system provides, and you don't worry about it.  In other 
situations (such as in small embedded systems), you think about it all 
the time - again, regardless of any VLAs.

If you are in a position where you suspect you might be pushing close to 
the limits of your stack, "standard" doesn't come into it - you are 
dealing with a particular target, and you can use whatever functions or 
support that target provides.

> These may be points that you are looking at for your embedded work,
> but the average programmer does not.
> 

The average programmer can think "I've got megabytes of stack.  There's 
no problem with VLAs of several KB."  That's often fine - all you need 
to do is be sure that your VLA's are a no more than a few KB in size. 
Your code is as safe (in this aspect) as pretty much any other piece of 
code on the platform.

> An example, Fortran-specific:  Fortran 2018 made all procedures
> recursive by default.  This means that some Fortran codes will start
> crashing because of stack overruns when this is implemented :-(
> 
>> 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.
> 
> What would you recommend as a limt?  (See fmax-stack-var-size=N
> in gfortran).

Maybe 50 KB ?  It's going to depend highly on the code.  Obviously if 
you have a recursive function, you are not going to want a big stack 
frame.  But for occasional one-off use, big stack frames are fine - 
VLA's, fixed arrays, or anything else.  Once you are getting bigger than 
that, the overhead of malloc is probably negligible in measurable 
performance.  (There are others here who could do a far better job than 
I at estimating that accurately - I am more concerned with what 
influences code reliability.)

(gcc has stack frame limit flags for C and C++ too.  And it can generate 
reports on function stack usage.  In all cases, it can only know about 
limits if they are fixed, or at least limited, at compile time.)