Darren New <dne### [at] sanrrcom> wrote:
> On 6/22/2011 13:07, Warp wrote:
> > (but the end result is probably an abort()).

> I would be very, very surprised if it wasn't undefined behavior to violate 
> the limits of the stack space.  There's just no good efficient portable way 
> of checking on hardware that doesn't do per-access checks (i.e., like a Z80 
> or something).

  You can violate any space by poking with pointers and offset at wild,
but the question was what happens if a function recurses too much and the
function calls run out of stack space.

  The official standard probably defines it as either undefined behavior
or implementation defined, but in practice what happens in most systems
is that the C runtime asks the OS to increase the stack space for that
process, the OS says nope, and then the C runtime aborts with some message.

>  > In many systems the size of the stack can actually be defined from
> > the outside (iow. the you tell the OS how much stack space it should reserve
> > for the program you are going to run).

> And that's why I'm thinking it can't really be implementation-defined, 
> unless the implementation is allowed to define it as "ask the OS."

  AFAIK in most systems the C runtime does indeed ask the OS to increase
the stack space as needed (in a similar way as it asks the OS to increase
heap space as needed).

-- 
                                                          - Warp

Post a reply to this message