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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#82634

Juha Nieminen <nospam@thanks.invalid> writes:

> 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.

Yes, these are too often confused, which does not help the discussion.

> 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.

In the most general cases, yes, but some languages actually specify that
certain recursive calls will not use a new data frame.  (The point being
that recursion does not always require a stack.)

-- 
Ben.

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

#82645

On 12/14/2021 8:14 AM, Ben Bacarisse wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
> 
>> 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.
> 
> Yes, these are too often confused, which does not help the discussion.
> 
>> 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.
> 
> In the most general cases, yes, but some languages actually specify that
> certain recursive calls will not use a new data frame.  (The point being
> that recursion does not always require a stack.)
> 

Fwiw, when I write something that's recursive, I always end up thinking 
about how to create an iterative version of it. Here is the iterative 
version of a recursive fractal I created a while back:

https://pastebin.com/raw/0B7rNx9Z
______________________
// Fractal Parametric Wave Plotter
void ct_fwave_mpara(
     ct::plot2d& plot,
     unsigned int n,
     ct_complex p0,
     ct_complex p1,
     unsigned int nr
) {
     ct_complex dif = p1 - p0;
     // Build the Fractal wave
     ct_float abase = 1.0 / n;
     ct_float abase_wave = CT_PI * 1 / n;
     for (unsigned int i = 0; i < n; i++)
     {
         ct_float angle = abase * i;
         ct_float angle_wave = abase_wave * i * nr;
         ct_float y_temp = abs(sin(angle_wave)) * 1.0 / nr + (p0.imag() 
+ (dif.imag() * angle));

         // Fractal Wave High
         ct_complex wp0 = {
             p0.real() + (dif.real() * angle),
             y_temp
         };

         // Fractal Wave Low
         ct_complex wp1 = {
             p0.real() + (dif.real() * angle),
             -y_temp
         };

         plot.set_pixelf(wp0, CT_RGBF(1., 1., 0.));
         plot.set_pixelf(wp1, CT_RGBF(0., 1., 1.));
     }
}

// Fractal Parametric Wave Function
void ct_fwave(
     ct::plot2d& plot,
     unsigned int n,
     ct_complex p0,
     ct_complex p1,
     unsigned int nr
) {
     // For every level
     for (unsigned int recur_i = 0; recur_i < n; ++recur_i)
     {
         // Plot the wave
         ct_fwave_mpara(plot, 3072, p0, p1, nr);

         // Compute next wave
         nr = nr * (recur_i + 2);
     }
}
______________________

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

#82633

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

> 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.

IBM mainframes did this.  The System 360 was the one knew.  The modern
versions probably use the same plan, unless they are running a Unix
flavour.

-- 
Ben.

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

#82636

Am 14.12.2021 um 09:13 schrieb David Brown:

> 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....

That's also a stack.

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

#82637

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 14.12.2021 um 09:13 schrieb David Brown:
>
>> 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....
>
>That's also a stack.
>

No, it's a linked list.   Unordered and non-contiguous.

But then you're just arguing for the sake of argument.

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

#82638

Am 14.12.2021 um 18:09 schrieb Scott Lurndal:

>>> 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....

>> That's also a stack.

> No, it's a linked list.   Unordered and non-contiguous.

A linked list can also be a stack if you add and remove items
only at one end.

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

#82640

scott@slp53.sl.home (Scott Lurndal) writes:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>Am 14.12.2021 um 09:13 schrieb David Brown:
>>
>>> 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....
>>
>>That's also a stack.
>
> No, it's a linked list.   Unordered and non-contiguous.

Unordered and non-contiguous *in memory*, but logically ordered.

As I and others have mentioned, the word "stack" can refer either to a
contiguous region of memory or to an arbitrary data structure managed in
a last-in first-out manner.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#82639

David Brown <david.brown@hesbynett.no> writes:
> 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 (at least) two distinct meanings of "stack".

One is a contiguous region of memory used to allocate memory for
function calls, growing in one direction in the address space and
shrinking in the other.  Most C implementations do use a "stack"
in this sense, but the standard doesn't specify it.

Another is any data structure that supports LIFO allocation and
deallocation.  *Every* C implementation has this kind of stack to
support the semantics of function calls, however it's implemented.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#82641

On 14/12/2021 19:52, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> 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 (at least) two distinct meanings of "stack".
> 
> One is a contiguous region of memory used to allocate memory for
> function calls, growing in one direction in the address space and
> shrinking in the other.  Most C implementations do use a "stack"
> in this sense, but the standard doesn't specify it.
> 
> Another is any data structure that supports LIFO allocation and
> deallocation.  *Every* C implementation has this kind of stack to
> support the semantics of function calls, however it's implemented.
> 

Agreed.

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

#82628

On 12/14/21 2:33 AM, 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.
> 

It may have a concetual stack, but doesn't need an actual hardware stack.

I have used a processor where a call instruction placed the return 
address at the targeted address, then started execution the instruction 
therafter.

If the function was marked as being recursive, then the beginning of the 
function would allocate a block of memory (like with malloc), copy this 
address, and any other local variables previously saved into that block, 
and the start the function. To return, those values were copied back, 
the block released and then a jump indirect the calling address was 
performed.

No stack in sight. Only something that was in effect a linked list, 
which can emmulate a stack.

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

#82631

On 13 Dec 2021 18:13, James Kuyper wrote:
> 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.

The C++ standard talks about e.g. "stack unwinding", which contradicts 
the assertion the neither standard uses the word (with this meaning).

There can be no systems where the concept of "stack" is meaningless, 
which contradicts the second assertion.

Perhaps you meant to write something else.


[snip]


Cheers, - Alf

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

#82635

On 12/14/21 10:19 AM, Alf P. Steinbach wrote:
> On 13 Dec 2021 18:13, James Kuyper wrote:
>> 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.
> 
> The C++ standard talks about e.g. "stack unwinding", which contradicts 
> the assertion the neither standard uses the word (with this meaning).

You're right. While I know a lot about both standards, I tend to be more
familiar with the C standard (which quite literally never uses the word
stack) than about C++ (which says almost nothing about "the stack"), so
I overstated my case.

The term "stack unwinding" is italicized in C++ 14.3p1, an ISO
convention indicating that the sentence containing that italicized
phrase constitutes the official definition of that term. That sentence is
"As control passes from the point where an exception is thrown to a
handler, objects with automatic storage duration are destroyed by a
process, specified in this subclause, called stack unwinding."

Keep in mind that there's a general principle that applies to phrases
with a meaning defined by the standard: you cannot in general break them
up into individual words and attack separate meanings to those words.
For example, in C, a "null pointer constant" need not be a pointer, it
could be an integer constant with a value of 0. In C++, a "null pointer
constant" cannot be a pointer - no pointer expressions meet the
requirements.

Similarly, you cannot derive any information about "the stack" from the
definition provided by C++ section 14.3 for "stack unwinding". While
that definition goes into considerable detail about initialization and
destruction of C++ objects, and the order in which those things occur,
it says nothing about where those objects may be located.

C++ section 14.3 implies LIFO ordering of the construction and
destruction of objects, but it only constrains the order in which the
memory they reside in is allocated and deallocated, it doesn't determine
that order. The memory can be allocated at any time prior to
construction of the object, and deallocated at any time subsequent to
the destruction of the object - those actions need not occur in LIFO
order. I don't know of any specific reason why there would be any
benefit in allocating the memory any earlier than absolutely necessary,
nor for deallocating it any later than absolutely necessary, but I would
not recommend ruling out the possibility that there might be some
benefits from doing so. Regardless of whether or not there's any good
reason to do so, an implementation of C++ which chose to would not
qualify as non-conforming, at least, not for that reason.

> There can be no systems where the concept of "stack" is meaningless, 
> which contradicts the second assertion.

I worded that badly, and apologize. It's not that the concept of a
"stack" is meaningless, C++ even provides std::stack<>.

My point was that the ideas that all computers must have a stack built
in, and that the rules for objects with automatic storage duration
mandate the use of that stack, are both incorrect.

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

#82609

On 12/13/2021 6:48 AM, 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?

The more general answer is that the standard (both C and C++) describes 
the behavior of an "abstract machine", and the requirement for actual 
conformant implementations is to produce the same "observable behavior" 
as the abstract machine.
The standard does not even mandate a stack [*]; it specifies the 
language rules for function calls, scope, local variables etc. all of 
which is commonly implemented via a memory stack, but that's the 
implementation, not the abstract machine.
The standard then connects back to the real world in Appendix B, where 
it says that limitations of finite systems may result in program 
constraints that should be documented by the implementation.
In this perspective such constraints fall under the "implementation 
defined" category.

> 
> 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).)

[*] The standard talks a.o. about "stack unwinding", thus referring to 
the common concept of a stack, but only to describe the process of 
destructing objects with automatic storage when leaving their scope. So, 
it's a concept related with scoping and lifetime, not with the stack 
memory structure.

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

#82648

On Mon, 2021-12-13, 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?

This is not an answer but: I'd rather have a tool which could do
static analysis and come up with an upper limit to stack usage. (It
would have to give less useful answers if the program used recursion
or C VLAs, but that's ok.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#82651

On 16/12/2021 00:27, Jorgen Grahn wrote:
> On Mon, 2021-12-13, 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?
> 
> This is not an answer but: I'd rather have a tool which could do
> static analysis and come up with an upper limit to stack usage. (It
> would have to give less useful answers if the program used recursion
> or C VLAs, but that's ok.)
> 

Such tools are available, and are not uncommon in embedded development
(where stacks are often /much/ smaller, and ram can be very limited).
There are lots of things that can make stack usage analysis difficult,
including threads, call-backs, and function pointers as well as the more
obvious points like recursion, alloca, or C VLA's.

gcc has some options for generating stack usage reports on functions, as
well as warnings for stack frames that grow too large and some run-time
stack checking.  I haven't made any real use of these, so I can't say
how helpful they might be.  (And I guess other compilers could have
similar features - gcc is just the one I know.)

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

#82614

Paavo Helde <eesnimi@osa.pri.ee> writes:

> 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.

It's important to distinguish the two realms of abstract machine
and actual machine.  In the abstract machine, the program shown
above (after fixing the problem of reading an uninitialized
variable) does have a well-defined specification, and the program
as a whole has defined behavior.  Whether a program has defined
behavior or undefined behavior is determined solely by what goes
on in the abstract machine (which may depend on values read from
a file or other input device, etc, but still the question is to
be answered considering only what happens in the abstract
machine, with reference to any actual machine).  Everything the
program does has a well-defined specification, and so the program
has only defined behavior, and no undefined behavior.

In an actual machine, an implementation is obliged to carry out
the abstract semantics only to the extent that the execution
does not exceed the implementation's "resource limits", which
might be anything at all, including stack space.  Once such a
resource limit is exceeded, the implementation has no further
obligations, and may abort, or whatever.  But that isn't the
same as undefined behavior, which depends solely on what the
standard says about operations in the abstract machine.

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

#82615

On Tuesday, 14 December 2021 at 06:16:23 UTC+8, Tim Rentsch wrote:
> Paavo Helde <ees...@osa.pri.ee> writes: 
> 
> > 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.
> It's important to distinguish the two realms of abstract machine 
> and actual machine. In the abstract machine, the program shown
> above (after fixing the problem of reading an uninitialized
> variable) does have a well-defined specification, and the program 
> as a whole has defined behavior. Whether a program has defined 
> behavior or undefined behavior is determined solely by what goes 
> on in the abstract machine (which may depend on values read from 
> a file or other input device, etc, but still the question is to 
> be answered considering only what happens in the abstract 
> machine, with reference to any actual machine). Everything the 
> program does has a well-defined specification, and so the program
> has only defined behavior, and no undefined behavior.
> In an actual machine, an implementation is obliged to carry out 
> the abstract semantics only to the extent that the execution 
> does not exceed the implementation's "resource limits", which 
> might be anything at all, including stack space. Once such a 
> resource limit is exceeded, the implementation has no further 
> obligations, and may abort, or whatever. But that isn't the 
> same as undefined behavior, which depends solely on what the 
> standard says about operations in the abstract machine.

If the concept of abstract (ideal) machine is used (the 1st time I heard this 
term in use).  The infinite recursive call should be defined as it is (never 
return, or infinite loop except semantics 'optimized' to differ), all functions 
within should be carried out successfully. But, for this ideal to be anything 
reasonable, there should at least one machine that can execute the program 
correctly.
If this is accepted, what should this 'actual machine' do with the infinite
recursive call?

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

#82657

wij <wyniijj@gmail.com> writes:

> On Tuesday, 14 December 2021 at 06:16:23 UTC+8, Tim Rentsch wrote:
>
>> Paavo Helde <ees...@osa.pri.ee> writes:
>>
>>> 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.
>>
>> It's important to distinguish the two realms of abstract machine
>> and actual machine.  In the abstract machine, the program shown
>> above (after fixing the problem of reading an uninitialized
>> variable) does have a well-defined specification, and the program
>> as a whole has defined behavior.  Whether a program has defined
>> behavior or undefined behavior is determined solely by what goes
>> on in the abstract machine (which may depend on values read from
>> a file or other input device, etc, but still the question is to
>> be answered considering only what happens in the abstract
>> machine, with reference to any actual machine).  Everything the
>> program does has a well-defined specification, and so the program
>> has only defined behavior, and no undefined behavior.
>> In an actual machine, an implementation is obliged to carry out
>> the abstract semantics only to the extent that the execution
>> does not exceed the implementation's "resource limits", which
>> might be anything at all, including stack space.  Once such a
>> resource limit is exceeded, the implementation has no further
>> obligations, and may abort, or whatever.  But that isn't the
>> same as undefined behavior, which depends solely on what the
>> standard says about operations in the abstract machine.
>
> If the concept of abstract (ideal) machine is used (the 1st time I
> heard this term in use).

The term "abstract machine" comes from the C++ standard (and
originally from the C standard).  It is not an ideal machine,
just an abstract machine, meaning there are some details it
doesn't pin down.

> The infinite recursive call should be defined as it is (never
> return, or infinite loop except semantics 'optimized' to differ),
> all functions within should be carried out successfully.

Because the abstract machine is abstract, it doesn't have any
notion of running out of memory.  The semantic descriptions
simply say another object instance is created, without any
concern about where memory for that object might come from.

> But, for this ideal to be anything reasonable, there should at
> least one machine that can execute the program correctly.

Again, the abstract machine is only abstract, not ideal.  Part of
the point of considering an abstract machine is the abstract
machine doesn't need to consider some things that actual machines
do.  It isn't possible to make an actual machine that faithfully
models the abstract machine, in much the same way that it isn't
possible to make an actual machine that faithfully models a
Turing machine.  Actual machines are always bounded;  Turing
machines, and the abstract machine, are potentially unbounded.

> If this is accepted, what should this 'actual machine' do with the
> infinite recursive call?

The premise that there is some actual machine that faithfully
models the abstract machine is wrong.  Since there is no such
actual machine, there is no answer to the question of what it
should do.  Any "actual machine" that can in fact be made will
at some point just run out of memory.

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

#82662

On Thursday, 16 December 2021 at 21:53:48 UTC+8, Tim Rentsch wrote:
> wij <wyn...@gmail.com> writes:
> > On Tuesday, 14 December 2021 at 06:16:23 UTC+8, Tim Rentsch wrote: 
> > 
> >> Paavo Helde <ees...@osa.pri.ee> writes: 
> >> 
> >>> 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. 
> >> 
> >> It's important to distinguish the two realms of abstract machine
> >> and actual machine. In the abstract machine, the program shown
> >> above (after fixing the problem of reading an uninitialized
> >> variable) does have a well-defined specification, and the program 
> >> as a whole has defined behavior. Whether a program has defined 
> >> behavior or undefined behavior is determined solely by what goes 
> >> on in the abstract machine (which may depend on values read from 
> >> a file or other input device, etc, but still the question is to 
> >> be answered considering only what happens in the abstract 
> >> machine, with reference to any actual machine). Everything the
> >> program does has a well-defined specification, and so the program
> >> has only defined behavior, and no undefined behavior.
> >> In an actual machine, an implementation is obliged to carry out 
> >> the abstract semantics only to the extent that the execution 
> >> does not exceed the implementation's "resource limits", which 
> >> might be anything at all, including stack space. Once such a 
> >> resource limit is exceeded, the implementation has no further 
> >> obligations, and may abort, or whatever. But that isn't the 
> >> same as undefined behavior, which depends solely on what the 
> >> standard says about operations in the abstract machine. 
> > 
> > If the concept of abstract (ideal) machine is used (the 1st time I 
> > heard this term in use). 
> 
> The term "abstract machine" comes from the C++ standard (and 
> originally from the C standard). It is not an ideal machine, 
> just an abstract machine, meaning there are some details it 
> doesn't pin down. 
> 
> > The infinite recursive call should be defined as it is (never 
> > return, or infinite loop except semantics 'optimized' to differ), 
> > all functions within should be carried out successfully. 
> 
> Because the abstract machine is abstract, it doesn't have any 
> notion of running out of memory. The semantic descriptions 
> simply say another object instance is created, without any 
> concern about where memory for that object might come from. 
> 
> > But, for this ideal to be anything reasonable, there should at 
> > least one machine that can execute the program correctly. 
> 
> Again, the abstract machine is only abstract, not ideal. Part of 
> the point of considering an abstract machine is the abstract 
> machine doesn't need to consider some things that actual machines 
> do. It isn't possible to make an actual machine that faithfully 
> models the abstract machine, in much the same way that it isn't 
> possible to make an actual machine that faithfully models a 
> Turing machine. Actual machines are always bounded; Turing 
> machines, and the abstract machine, are potentially unbounded. 
> 
> > If this is accepted, what should this 'actual machine' do with the 
> > infinite recursive call? 
> 
> The premise that there is some actual machine that faithfully 
> models the abstract machine is wrong. Since there is no such 
> actual machine, there is no answer to the question of what it 
> should do. Any "actual machine" that can in fact be made will 
> at some point just run out of memory.

Thanks for the explanation, I thought "abstract machine" is a new
invention to explain the language.

By the way, I though the 'stack' still must exist no matter how it is 
implemented. Because the process of RAII/function call and the
'auto' (old name) variables are mostly efficient in the stack.
These all added to be most efficient in one stack (or 'primary stack').

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

#82663

wij <wyniijj@gmail.com> writes:
[...]
> By the way, I though the 'stack' still must exist no matter how it is 
> implemented. Because the process of RAII/function call and the
> 'auto' (old name) variables are mostly efficient in the stack.
> These all added to be most efficient in one stack (or 'primary stack').

It depends on what you mean by "stack".

Most C++ implementations use a "stack" in the sense of a contiguous
region of memory managed via a pointer to the "top".

A contiguous memory "stack" (which is not required by the standard) is
the most common way to implement the abstract last-in first-out
semantics of function calls.  There are implementations (at least for C,
and probably for C++) that do something similar to a malloc call to
allocate storage for a new function call.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web