Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82600 > unrolled thread

Has "stack overflow" specified behavior?

Back to article view | Back to comp.lang.c++

Contents

  Has "stack overflow" specified behavior? wij <wyniijj@gmail.com> - 2021-12-12 00:42 -0800
    Re: Has "stack overflow" specified behavior? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-12 09:52 +0100
      Re: Has "stack overflow" specified behavior? red floyd <no.spam.here@its.invalid> - 2021-12-12 12:59 -0800
    Re: Has "stack overflow" specified behavior? Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-13 01:51 +0200
      Re: Has "stack overflow" specified behavior? Juha Nieminen <nospam@thanks.invalid> - 2021-12-13 05:48 +0000
        Re: Has "stack overflow" specified behavior? Bo Persson <bo@bo-persson.se> - 2021-12-13 10:44 +0100
          Re: Has "stack overflow" specified behavior? wij <wyniijj@gmail.com> - 2021-12-13 04:44 -0800
          Re: Has "stack overflow" specified behavior? Richard Damon <Richard@Damon-Family.org> - 2021-12-13 07:47 -0500
            Re: Has "stack overflow" specified behavior? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 08:32 +0100
              Re: Has "stack overflow" specified behavior? Richard Damon <Richard@Damon-Family.org> - 2021-12-14 07:49 -0500
                Re: Has "stack overflow" specified behavior? scott@slp53.sl.home (Scott Lurndal) - 2021-12-14 14:23 +0000
                Re: Has "stack overflow" specified behavior? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-12-14 16:16 +0100
          Re: Has "stack overflow" specified behavior? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-13 12:13 -0500
            Re: Has "stack overflow" specified behavior? Öö Tiib <ootiib@hot.ee> - 2021-12-13 12:05 -0800
              Re: Has "stack overflow" specified behavior? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-13 17:11 -0800
              Re: Has "stack overflow" specified behavior? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-13 19:00 -0800
                Re: Has "stack overflow" specified behavior? Öö Tiib <ootiib@hot.ee> - 2021-12-13 23:03 -0800
            Re: Has "stack overflow" specified behavior? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 08:33 +0100
              Re: Has "stack overflow" specified behavior? David Brown <david.brown@hesbynett.no> - 2021-12-14 09:13 +0100
                Re: Has "stack overflow" specified behavior? Juha Nieminen <nospam@thanks.invalid> - 2021-12-14 10:09 +0000
                  Re: Has "stack overflow" specified behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-14 16:14 +0000
                    Re: Has "stack overflow" specified behavior? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-14 15:23 -0800
                Re: Has "stack overflow" specified behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-14 16:10 +0000
                Re: Has "stack overflow" specified behavior? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 17:38 +0100
                  Re: Has "stack overflow" specified behavior? scott@slp53.sl.home (Scott Lurndal) - 2021-12-14 17:09 +0000
                    Re: Has "stack overflow" specified behavior? Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 18:39 +0100
                    Re: Has "stack overflow" specified behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-14 11:01 -0800
                Re: Has "stack overflow" specified behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-14 10:52 -0800
                  Re: Has "stack overflow" specified behavior? David Brown <david.brown@hesbynett.no> - 2021-12-14 20:15 +0100
              Re: Has "stack overflow" specified behavior? Richard Damon <Richard@Damon-Family.org> - 2021-12-14 07:59 -0500
            Re: Has "stack overflow" specified behavior? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-12-14 16:19 +0100
              Re: Has "stack overflow" specified behavior? James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-14 11:33 -0500
        Re: Has "stack overflow" specified behavior? Manfred <noname@add.invalid> - 2021-12-13 17:23 +0100
        Re: Has "stack overflow" specified behavior? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-12-15 23:27 +0000
          Re: Has "stack overflow" specified behavior? David Brown <david.brown@hesbynett.no> - 2021-12-16 08:37 +0100
      Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-13 14:16 -0800
        Re: Has "stack overflow" specified behavior? wij <wyniijj@gmail.com> - 2021-12-13 15:07 -0800
          Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 05:53 -0800
            Re: Has "stack overflow" specified behavior? wij <wyniijj@gmail.com> - 2021-12-16 08:34 -0800
              Re: Has "stack overflow" specified behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-16 12:17 -0800
                Re: Has "stack overflow" specified behavior? wij <wyniijj@gmail.com> - 2021-12-16 13:38 -0800
                  Re: Has "stack overflow" specified behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-16 14:15 -0800
              Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 20:10 -0800
            Re: Has "stack overflow" specified behavior? Öö Tiib <ootiib@hot.ee> - 2021-12-16 14:14 -0800
              Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 20:20 -0800
                Re: Has "stack overflow" specified behavior? Öö Tiib <ootiib@hot.ee> - 2021-12-17 08:46 -0800
        Re: Has "stack overflow" specified behavior? Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-14 10:32 +0200
          Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 07:42 -0800
            Re: Has "stack overflow" specified behavior? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-12-17 01:07 +0000
              Re: Has "stack overflow" specified behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-17 01:28 +0000
              Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 19:54 -0800
                Re: Has "stack overflow" specified behavior? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-12-17 10:06 +0000
    Re: Has "stack overflow" specified behavior? Manfred <noname@add.invalid> - 2021-12-13 17:08 +0100
      Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-13 13:50 -0800
        Re: Has "stack overflow" specified behavior? Manfred <noname@add.invalid> - 2021-12-14 16:32 +0100
    Re: Has "stack overflow" specified behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-13 13:13 -0800
    Re: Has "stack overflow" specified behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-13 15:55 -0800
      Re: Has "stack overflow" specified behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-13 15:58 -0800
      Re: Has "stack overflow" specified behavior? wij <wyniijj@gmail.com> - 2021-12-14 01:41 -0800

Page 1 of 3  [1] 2 3  Next page →

#82600 — Has "stack overflow" specified behavior?

void t() {
  int a;
  ++a;
  t();
};

int main()
{
 t();
}

---
Has "stack overflow" specified behavior?

[toc] | [next] | [standalone]

#82601

Am 12.12.2021 um 09:42 schrieb wij:
> void t() {
>    int a;
>    ++a;
>    t();
> };
> 
> int main()
> {
>   t();
> }
> 
> ---
> Has "stack overflow" specified behavior?

If you're lucky a stack overflow even won't happen because the com-
piler will detect the tail-recursion and convert it into an iteration.

[toc] | [prev] | [next] | [standalone]

#82602

On 12/12/2021 12:52 AM, Bonita Montero wrote:
> Am 12.12.2021 um 09:42 schrieb wij:
>> void t() {
>>    int a;
>>    ++a;
>>    t();
>> };
>>
>> int main()
>> {
>>   t();
>> }
>>
>> ---
>> Has "stack overflow" specified behavior?
> 
> If you're lucky a stack overflow even won't happen because the com-
> piler will detect the tail-recursion and convert it into an iteration.

Not to mention the potential UB with the use-before-initialization of
the ++a; statement.

[toc] | [prev] | [next] | [standalone]

#82603

12.12.2021 10:42 wij kirjutas:
> void t() {
>    int a;
>    ++a;
>    t();
> };
> 
> int main()
> {
>   t();
> }
> 
> ---
> Has "stack overflow" specified behavior?
> 

No. Stack overflow is arguably the least specified behavior of them all. 
The stack size is extremely limited (few MB), compared to the RAM 
amounts current computers have (tens of GB). There is no 
standard-defined way to detect stack overflow, not to speak about 
handling it. That's one reason why using stack-allocated things like 
std::array needs special care, especially when writing libraries (which 
need to execute in a stack of unknown size and fill-up).

There are some implementation-defined ways though to survive stack 
overflows, but it's not so easy. You cannot continue the program if 
there is no more stack space, so the only way is to throw an exception. 
Alas, there is no "throw" statement in the code, so this would be an 
"asynchronous" exception appearing at a pretty random place in the code, 
meaning that the compiler must cope with such exceptions, which may 
easily slow down the whole program (witness the /EHa compiler option in 
MSVC).

BTW, your example code is not guaranteed to cause stack overflow, it 
might go into an infinite loop instead because of tail recursion, or 
become a zero op by optimizing the whole t() function away, either as UB 
or as a code with no effect.

[toc] | [prev] | [next] | [standalone]

#82604

Paavo Helde <eesnimi@osa.pri.ee> wrote:
> No. Stack overflow is arguably the least specified behavior of them all. 
> The stack size is extremely limited (few MB), compared to the RAM 
> amounts current computers have (tens of GB). There is no 
> standard-defined way to detect stack overflow, not to speak about 
> handling it.

That made me think: Why has neither the C nor the C++ standardization
committees ever thought of adding a standard library utility to get
the current amount of free stack space?

Sure, perhaps in some operating systems this isn't something that
programs can get, but the function in question could be optional in
that sense. For example it could return -1 to indicate "this operation
is not supported", else a non-negative value to indicate the amount
of free stack space. This could give programs at least the opportunity
to gracefully do something if running out of stack space. I think this
could be useful especially in programs that need to be as stable and
secure as possible.

(In fact, getting the amount of free (physical) RAM available to the
process could also be useful, for similar reasons. It could behave
in the same way: -1 if the operation is for some reason not supported,
else the amount of free RAM (not counting swap).)

[toc] | [prev] | [next] | [standalone]

#82605

On 2021-12-13 at 06:48, Juha Nieminen wrote:
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>> No. Stack overflow is arguably the least specified behavior of them all.
>> The stack size is extremely limited (few MB), compared to the RAM
>> amounts current computers have (tens of GB). There is no
>> standard-defined way to detect stack overflow, not to speak about
>> handling it.
> 
> That made me think: Why has neither the C nor the C++ standardization
> committees ever thought of adding a standard library utility to get
> the current amount of free stack space?
> 
> Sure, perhaps in some operating systems this isn't something that
> programs can get, but the function in question could be optional in
> that sense. For example it could return -1 to indicate "this operation
> is not supported", else a non-negative value to indicate the amount
> of free stack space. This could give programs at least the opportunity
> to gracefully do something if running out of stack space. I think this
> could be useful especially in programs that need to be as stable and
> secure as possible.
> 
> (In fact, getting the amount of free (physical) RAM available to the
> process could also be useful, for similar reasons. It could behave
> in the same way: -1 if the operation is for some reason not supported,
> else the amount of free RAM (not counting swap).)

This would be of very limited use. The result of a call from one thread 
wouldn't be valid long, if the other threads allocate and free memory 
already while the result is returned.

It is similar to filesystem::exists("path"). If you get a true or false 
back, how long is the result valid? Nanoseconds?

[toc] | [prev] | [next] | [standalone]

#82606

On Monday, 13 December 2021 at 17:44:58 UTC+8, Bo Persson wrote:
> On 2021-12-13 at 06:48, Juha Nieminen wrote: 
> > Paavo Helde <ees...@osa.pri.ee> wrote: 
> >> No. Stack overflow is arguably the least specified behavior of them all. 
> >> The stack size is extremely limited (few MB), compared to the RAM 
> >> amounts current computers have (tens of GB). There is no 
> >> standard-defined way to detect stack overflow, not to speak about 
> >> handling it. 
> > 
> > That made me think: Why has neither the C nor the C++ standardization 
> > committees ever thought of adding a standard library utility to get 
> > the current amount of free stack space? 
> > 
> > Sure, perhaps in some operating systems this isn't something that 
> > programs can get, but the function in question could be optional in 
> > that sense. For example it could return -1 to indicate "this operation 
> > is not supported", else a non-negative value to indicate the amount 
> > of free stack space. This could give programs at least the opportunity 
> > to gracefully do something if running out of stack space. I think this 
> > could be useful especially in programs that need to be as stable and 
> > secure as possible. 
> > 
> > (In fact, getting the amount of free (physical) RAM available to the 
> > process could also be useful, for similar reasons. It could behave 
> > in the same way: -1 if the operation is for some reason not supported, 
> > else the amount of free RAM (not counting swap).)
> This would be of very limited use. The result of a call from one thread 
> wouldn't be valid long, if the other threads allocate and free memory 
> already while the result is returned. 
> 
> It is similar to filesystem::exists("path"). If you get a true or false 
> back, how long is the result valid? Nanoseconds?

If such a function is useful, the duration the value valid is not a problem.
The only useful cases I have are when implementing 'synchronized' thread
 (not sure about the name) or the function algorithm uses stack heavily, e.g.
when the size of an object is significantly large.

[toc] | [prev] | [next] | [standalone]

#82607

On 12/13/21 4:44 AM, Bo Persson wrote:
> On 2021-12-13 at 06:48, Juha Nieminen wrote:
>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> No. Stack overflow is arguably the least specified behavior of them all.
>>> The stack size is extremely limited (few MB), compared to the RAM
>>> amounts current computers have (tens of GB). There is no
>>> standard-defined way to detect stack overflow, not to speak about
>>> handling it.
>>
>> That made me think: Why has neither the C nor the C++ standardization
>> committees ever thought of adding a standard library utility to get
>> the current amount of free stack space?
>>
>> Sure, perhaps in some operating systems this isn't something that
>> programs can get, but the function in question could be optional in
>> that sense. For example it could return -1 to indicate "this operation
>> is not supported", else a non-negative value to indicate the amount
>> of free stack space. This could give programs at least the opportunity
>> to gracefully do something if running out of stack space. I think this
>> could be useful especially in programs that need to be as stable and
>> secure as possible.
>>
>> (In fact, getting the amount of free (physical) RAM available to the
>> process could also be useful, for similar reasons. It could behave
>> in the same way: -1 if the operation is for some reason not supported,
>> else the amount of free RAM (not counting swap).)
> 
> This would be of very limited use. The result of a call from one thread 
> wouldn't be valid long, if the other threads allocate and free memory 
> already while the result is returned.
> 
> It is similar to filesystem::exists("path"). If you get a true or false 
> back, how long is the result valid? Nanoseconds?
> 
> 

Actually, most threading libraries creat threads with a FIXED sized 
stack (specified in the create call or it uses a default), and that 
space is all reserved for the thread stack.

Only the main thread tends to have an expandable stack, which often 
grows into the heap, so only the main thread would be affected by other 
threads activities.

I suspect that part of the issue is that while it would normally be 
possible to compute how much address space is available for the stack, 
it can be more complicated to figure out if you can map usable ram into 
that address space, and with the Linux over-commit issue, the straight 
answer might easily be not available, or expensive to compute.

Also, this is something easy for a system to add as a system defined 
function, that works for it. The fact that this isn't commonly available 
seems to be a sign that it isn't really easy to provide what might be 
needed, or it isn't really needed.

[toc] | [prev] | [next] | [standalone]

#82621

Am 13.12.2021 um 13:47 schrieb Richard Damon:

> Actually, most threading libraries creat threads with a FIXED sized 
> stack (specified in the create call or it uses a default), and that 
> space is all reserved for the thread stack.

How would an implementation of a variable stack space look like when
the stack can't be moved because of pointers inside the stack-frames ?

[toc] | [prev] | [next] | [standalone]

#82627

On 12/14/21 2:32 AM, Bonita Montero wrote:
> Am 13.12.2021 um 13:47 schrieb Richard Damon:
> 
>> Actually, most threading libraries creat threads with a FIXED sized 
>> stack (specified in the create call or it uses a default), and that 
>> space is all reserved for the thread stack.
> 
> How would an implementation of a variable stack space look like when
> the stack can't be moved because of pointers inside the stack-frames ?
> 

It doesn't.

The Thread APIs I know create a FIXED size stack for a new thread and it 
can not be changed/moved after the thread is started.

The fact that there can exist pointers to data on the stack (possible on 
the stack) is one big reason for this limitation.

Just like if you use realloc you need to be careful of dangling 
references to the old buffer, trying to move a thread stack is a hard, 
likely impossible, problem.

The main thread stack can be expandable, as it often has a special 
relationship to the heap, so you can trade memory between the stack and 
the heap. There is normally only one such special location.

I suppose you could grossly over-allocate the stack space for a thread 
and then create some sort of auxiliary heap at the end of it, and trade 
of use of that heap with stack space for that thread.

[toc] | [prev] | [next] | [standalone]

#82629

Richard Damon <Richard@Damon-Family.org> writes:
>
>On 12/14/21 2:32 AM, Bonita Montero wrote:
>> Am 13.12.2021 um 13:47 schrieb Richard Damon:
>> 
>>> Actually, most threading libraries creat threads with a FIXED sized 
>>> stack (specified in the create call or it uses a default), and that 
>>> space is all reserved for the thread stack.
>> 
>> How would an implementation of a variable stack space look like when
>> the stack can't be moved because of pointers inside the stack-frames ?
>> 
>
>It doesn't.
>
>The Thread APIs I know create a FIXED size stack for a new thread and it 
>can not be changed/moved after the thread is started.
>
>The fact that there can exist pointers to data on the stack (possible on 
>the stack) is one big reason for this limitation.
>
>Just like if you use realloc you need to be careful of dangling 
>references to the old buffer, trying to move a thread stack is a hard, 
>likely impossible, problem.

We did that in a bare-metal hypervisor last decade:

/**
 * Initialize the per-core DVMM stack.
 *
 *      Allocate a pages for the stack and copy the stack
 *      content from the bootstrap stack to the newly allocated stack,
 *      adjusting any values on the bootstrap stack that appear to be
 *      addresses of objects in the boot stack (primarily the saved rbp
 *      register values).
 *
 *      Since the stack grows towards lower addresses, we'll allocate a
 *      guard area (of #c_as::GUARD_PAGES in length) immediately before the
 *      per-core stack.  The guard area is implemented by unmapping the
 *      virtual address(es) corresponding to the guard area. If a stack
 *      push or call op causes the stack to enter this region,
 *      a \#PF exception will be thrown.
 */
void
c_core::initialize_stack(void)
{
    uintptr_t offset;
    MFN       mfn;

    mfn = node->local_mem()->allocate_contig(
                                BYTE_COUNT_TO_PAGES(EXCEPTION_STACK_SIZE),
                                0, socket_num, c_page_allocator::LOC_FIRST);
    ASSERT(mfn != ENOMFN);
    exception_stack = (uintptr_t)ma_to_ptr(mfn.to_ma());

    mfn = node->local_mem()->allocate_contig(
                                BYTE_COUNT_TO_PAGES(STACK_SIZE) + GUARD_PAGES,
                                0, socket_num, c_page_allocator::LOC_FIRST);
    // CPU stack pages should not come out of export mem
    ASSERT(mfn != ENOMFN);
    stack = (uintptr_t)ma_to_ptr(mfn.to_ma());

    unmap(PAGE_NUMBER(stack), GUARD_PAGES);
    stack += GUARD_PAGES * PAGE_SIZE;

    ASSERT((ptrdiff_t)(init_stack_top - init_stack) == (ptrdiff_t)STACK_SIZE);

    memcpy((void *)stack, init_stack, STACK_SIZE);

    //
    // Make sure any stack pointers on the stack get adjusted too.
    //
    offset = get_rsp() - (uintptr_t)init_stack;

    for(uintptr_t sp = stack + offset;
        sp < (stack + STACK_SIZE);
        sp += sizeof(uintptr_t)) {
        uintptr_t  qword = *(uintptr_t *)sp;

        if ((qword >= (uintptr_t)init_stack)
         && (qword <= (uintptr_t)init_stack_top)) {
            *(uintptr_t *)sp = stack + (qword - (uintptr_t)init_stack);
        }
    }
    set_rsp(stack + offset);
    set_rbp(stack + (get_rbp() - (uintptr_t)init_stack));
}

[toc] | [prev] | [next] | [standalone]

#82630

On 14 Dec 2021 13:49, Richard Damon wrote:
> 
> On 12/14/21 2:32 AM, Bonita Montero wrote:
>> Am 13.12.2021 um 13:47 schrieb Richard Damon:
>>
>>> Actually, most threading libraries creat threads with a FIXED sized 
>>> stack (specified in the create call or it uses a default), and that 
>>> space is all reserved for the thread stack.
>>
>> How would an implementation of a variable stack space look like when
>> the stack can't be moved because of pointers inside the stack-frames ?
>>
> 
> It doesn't.
> 
> The Thread APIs I know create a FIXED size stack for a new thread and it 
> can not be changed/moved after the thread is started.
> 
> The fact that there can exist pointers to data on the stack (possible on 
> the stack) is one big reason for this limitation.
> 
> Just like if you use realloc you need to be careful of dangling 
> references to the old buffer, trying to move a thread stack is a hard, 
> likely impossible, problem.
> 
> The main thread stack can be expandable, as it often has a special 
> relationship to the heap, so you can trade memory between the stack and 
> the heap. There is normally only one such special location.
> 
> I suppose you could grossly over-allocate the stack space for a thread 
> and then create some sort of auxiliary heap at the end of it, and trade 
> of use of that heap with stack space for that thread.

It's technically possible to use (that is, for the compiler to support) 
a linked list based stack, and that could be preferable for real coroutines.

AFAIK no compiler linked list stack by default, but apparently gcc 
supports, or at least did support when one used the "gold linker", a 
scheme called a "split stack".

I'm not sure but googling it now and looking at the first hit it seems 
that the compiler generates additional stack checking instructions that 
allocates and links up a new stack part when the current is too small. 
I.e. this is not a linked list of stack frames but a linked list of 
stack parts.

https://gcc.gnu.org/wiki/SplitStacks

---

With 64-bit addressing and a reasonably low number of threads I guess 
one could in principle just allocate a largish address range for each 
stack, and expand the backing in terms of real memory pages, as needed, 
perhaps with the need detected via a guard page to avoid overhead of 
stack size checking code in every function.

E.g. in Windows pages are managed via `VirtualAlloc` function & friends.

But I haven't heard of such scheme being used.


- Alf

[toc] | [prev] | [next] | [standalone]

#82610

On 12/13/21 4:44 AM, Bo Persson wrote:
> On 2021-12-13 at 06:48, Juha Nieminen wrote:
>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>> No. Stack overflow is arguably the least specified behavior of them all.
>>> The stack size is extremely limited (few MB), compared to the RAM
>>> amounts current computers have (tens of GB). There is no
>>> standard-defined way to detect stack overflow, not to speak about
>>> handling it.
>>
>> That made me think: Why has neither the C nor the C++ standardization
>> committees ever thought of adding a standard library utility to get
>> the current amount of free stack space?

A key factor in that decision is the fact that neither the C nor the C++
standard ever talks about the stack space, a fact that allows either
language to be implemented on systems where the concept of "stack" is
meaningless.
On operating systems where the concept is meaningful, there often is a
way to conduct such a query. For instance, on Unix-like systems, there's
getrlimit(RLIMIT_STACK, &rlim).

,,,
>> (In fact, getting the amount of free (physical) RAM available to the
>> process could also be useful, for similar reasons. It could behave
>> in the same way: -1 if the operation is for some reason not supported,
>> else the amount of free RAM (not counting swap).)
> 
> This would be of very limited use. The result of a call from one thread 
> wouldn't be valid long, if the other threads allocate and free memory 
> already while the result is returned.
> 
> It is similar to filesystem::exists("path"). If you get a true or false 
> back, how long is the result valid? Nanoseconds?

There's an important difference: as a matter of the policies you use for
managing a filesystem (rather than anything enforced by the operating
system), it is not only possible, but commonplace, to be certain that a
given file, if present, will remain in existence long enough to do
whatever it is you want to do with it.
That's not the case with the amount of free stack space.

[toc] | [prev] | [next] | [standalone]

#82611

On Monday, 13 December 2021 at 19:13:58 UTC+2, james...@alumni.caltech.edu wrote:
> On 12/13/21 4:44 AM, Bo Persson wrote:
> > On 2021-12-13 at 06:48, Juha Nieminen wrote: 
> >> Paavo Helde <ees...@osa.pri.ee> wrote: 
> >>> No. Stack overflow is arguably the least specified behavior of them all. 
> >>> The stack size is extremely limited (few MB), compared to the RAM 
> >>> amounts current computers have (tens of GB). There is no 
> >>> standard-defined way to detect stack overflow, not to speak about 
> >>> handling it. 
> >> 
> >> That made me think: Why has neither the C nor the C++ standardization 
> >> committees ever thought of adding a standard library utility to get 
> >> the current amount of free stack space?
>
> A key factor in that decision is the fact that neither the C nor the C++ 
> standard ever talks about the stack space, a fact that allows either 
> language to be implemented on systems where the concept of "stack" is 
> meaningless. 

That feels like quite odd argument. How can that distract anyone from
fact that every implementation has to have some kind of storage
that is used for storing objects with automatic storage duration? Neither
standard denies that it has to exist nor that it is potentially limited.
Avoiding naming it with some shorter name does not make it
disappear from abstract machine. It may run out of available space
and the standards avoid providing any ways to estimate that space
or to handle that event.

[toc] | [prev] | [next] | [standalone]

#82618

On Monday, December 13, 2021 at 3:06:11 PM UTC-5, Öö Tiib wrote:
> On Monday, 13 December 2021 at 19:13:58 UTC+2, james...@alumni.caltech.edu wrote: 
> > On 12/13/21 4:44 AM, Bo Persson wrote: 
> > > On 2021-12-13 at 06:48, Juha Nieminen wrote: 
> > >> Paavo Helde <ees...@osa.pri.ee> wrote: 
> > >>> No. Stack overflow is arguably the least specified behavior of them all. 
> > >>> The stack size is extremely limited (few MB), compared to the RAM 
> > >>> amounts current computers have (tens of GB). There is no 
> > >>> standard-defined way to detect stack overflow, not to speak about 
> > >>> handling it. 
> > >> 
> > >> That made me think: Why has neither the C nor the C++ standardization 
> > >> committees ever thought of adding a standard library utility to get 
> > >> the current amount of free stack space? 
> > 
> > A key factor in that decision is the fact that neither the C nor the C++ 
> > standard ever talks about the stack space, a fact that allows either 
> > language to be implemented on systems where the concept of "stack" is 
> > meaningless.
> That feels like quite odd argument. How can that distract anyone from 
> fact that every implementation has to have some kind of storage 
> that is used for storing objects with automatic storage duration? Neither 
> standard denies that it has to exist nor that it is potentially limited. 
> Avoiding naming it with some shorter name does not make it 
> disappear from abstract machine. It may run out of available space 
> and the standards avoid providing any ways to estimate that space 
> or to handle that event.

[toc] | [prev] | [next] | [standalone]

#82619

On Monday, December 13, 2021 at 3:06:11 PM UTC-5, Öö Tiib wrote:
> On Monday, 13 December 2021 at 19:13:58 UTC+2, james...@alumni.caltech.edu wrote: 
...
> > A key factor in that decision is the fact that neither the C nor the C++ 
> > standard ever talks about the stack space, a fact that allows either 
> > language to be implemented on systems where the concept of "stack" is 
> > meaningless.
> That feels like quite odd argument. How can that distract anyone from 
> fact that every implementation has to have some kind of storage 
> that is used for storing objects with automatic storage duration? Neither 
> standard denies that it has to exist nor that it is potentially limited. 
> Avoiding naming it with some shorter name does not make it 
> disappear from abstract machine. It may run out of available space 
> and the standards avoid providing any ways to estimate that space 
> or to handle that event.

Because calling it a stack carries implications that a typical hardware
stack must be involved, using memory that's completely distinct from the
heap, with each function call's local variables being pushed onto the stack
immediately between the local variables for the calling routine, and the
local variables for the routines it calls.
There are real world machines with no hardware stack. Some of them
dynamically allocate something called "activation records" to store such
objects, the same way they allocate memory when malloc() is called. While
the function call hierarchy means that memory used for objects with
automatic storage duration has LIFO semantics, the activation record for a
calling function need not be anywhere near the activation record for the
called function. And there's no need for such memory to be allocated and
deallocated strictly in LIFO  order. The activation record for a given function
call must be allocated some time before the function call starts executing,
but it needn't be allocated immediately before it. An activation record must
not be deallocated until after the function call ends, but it needn't be
deallocated immediately afterward. 
For all those reasons, calling it a stack would be a bad idea, because it
would give too many false impressions about what is required.

[toc] | [prev] | [next] | [standalone]

#82620

On Tuesday, 14 December 2021 at 05:00:53 UTC+2, james...@alumni.caltech.edu wrote:
> On Monday, December 13, 2021 at 3:06:11 PM UTC-5, Öö Tiib wrote: 
> > On Monday, 13 December 2021 at 19:13:58 UTC+2, james...@alumni.caltech.edu wrote:
> ...
> > > A key factor in that decision is the fact that neither the C nor the C++ 
> > > standard ever talks about the stack space, a fact that allows either 
> > > language to be implemented on systems where the concept of "stack" is 
> > > meaningless. 
> > That feels like quite odd argument. How can that distract anyone from 
> > fact that every implementation has to have some kind of storage 
> > that is used for storing objects with automatic storage duration? Neither 
> > standard denies that it has to exist nor that it is potentially limited. 
> > Avoiding naming it with some shorter name does not make it 
> > disappear from abstract machine. It may run out of available space 
> > and the standards avoid providing any ways to estimate that space 
> > or to handle that event.
> Because calling it a stack carries implications that a typical hardware 
> stack must be involved, using memory that's completely distinct from the 
> heap, with each function call's local variables being pushed onto the stack 
> immediately between the local variables for the calling routine, and the 
> local variables for the routines it calls. 
> There are real world machines with no hardware stack. Some of them 
> dynamically allocate something called "activation records" to store such 
> objects, the same way they allocate memory when malloc() is called. While 
> the function call hierarchy means that memory used for objects with 
> automatic storage duration has LIFO semantics, the activation record for a 
> calling function need not be anywhere near the activation record for the 
> called function. And there's no need for such memory to be allocated and 
> deallocated strictly in LIFO order. The activation record for a given function 
> call must be allocated some time before the function call starts executing, 
> but it needn't be allocated immediately before it. An activation record must 
> not be deallocated until after the function call ends, but it needn't be 
> deallocated immediately afterward. 
> For all those reasons, calling it a stack would be a bad idea, because it 
> would give too many false impressions about what is required.

OK.  However consecutive elements being adjacent in memory is not implied
property of "stack" in C++. Any attempt to treat adjacently defined
objects with automatic storage as adjacent in memory is undefined 
behavior. Also the LIFO container adapter std::stack uses
std::deque as default underlying container and so lacks that property.
So while you are correct that typical hardware stack has certain handy
properties ... those are commonly out of reach of C++ programmer unless
implementation takes to define additional guarantees as extension. 

[toc] | [prev] | [next] | [standalone]

#82622

Am 13.12.2021 um 18:13 schrieb James Kuyper:

> A key factor in that decision is the fact that neither the C nor the C++
> standard ever talks about the stack space, a fact that allows either
> language to be implemented on systems where the concept of "stack" is
> meaningless.

Every language that allows recursions has a stack.
And both C and C++ allow recursions.

[toc] | [prev] | [next] | [standalone]

#82623

On 14/12/2021 08:33, Bonita Montero wrote:
> Am 13.12.2021 um 18:13 schrieb James Kuyper:
> 
>> A key factor in that decision is the fact that neither the C nor the C++
>> standard ever talks about the stack space, a fact that allows either
>> language to be implemented on systems where the concept of "stack" is
>> meaningless.
> 
> Every language that allows recursions has a stack.
> And both C and C++ allow recursions.
> 

As so often happens, your views are coloured by your "all the world is
an x86 running Windows" experience.


Certainly stacks are the usual way to implement such languages.

But they are not the only way - AFAIK there have been computers that
used a linked list of local data frames rather than a stack.  There are
also systems with two stacks - one for data, one for return addresses.
And there are lots of small systems implementing C that only have very
inefficient implementations for recursive functions because of poor
hardware support for stacks, and do not use a stack for code unless a
function actually is recursive.

C (and to a lesser extent C++) is designed to be implementable on a very
wide range of systems.  Adding features that are specific to particular
kinds of implementations limits that flexibility.  It might be worth
doing, of course - some kinds of systems could be viewed as outdated, or
we could simply say that they only implement a subset of the language
standard.  (As an example, with C++20, and C2x, two's complement signed
integer representation is now blessed as the only option.)  But these
things are not to be taken lightly or arbitrarily.

[toc] | [prev] | [next] | [standalone]

#82626

David Brown <david.brown@hesbynett.no> wrote:
>> Every language that allows recursions has a stack.
>> And both C and C++ allow recursions.
> 
> As so often happens, your views are coloured by your "all the world is
> an x86 running Windows" experience.
> 
> Certainly stacks are the usual way to implement such languages.

I think in this context a distinction should be made between the concept
of a "stack" in the algorithm / computer science sense, and a "stack" in
the sense of a particular implementation of one.

In the computer science sense a "stack" is pretty much a synonym for
"a LIFO data container". However, how exactly that LIFO container is
implemented is not set in stone.

Recursion does indeed require a stack by necessity. However, any
dynamic LIFO data container will do for this, and thus no specific
implementation is imposed.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web