In article <39a0fd7f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Why? This is a bit silly. I don't see any reason to limit the recursion
> level of macros. That's what dynamic memory allocation is for.

Not on all systems the stack is at the other 4 GB (or even 2^64 Byte) end
of the address space. In fact, even on such a system, once stack and heap
together take more than the per address (register) size limit, they will
collide...

Besides, it would be _very_ dangerous for a good operating system to allow a
stack over a specific size.  Take this simple program* for example, it will
consume all your memory resources (even if you run out of process table
entries, assuming this does not result in a signal):

#include <sys/types.h>
#include <unistd.h>

void main(void)
{
    (void)fork();
    main();
}

Now, you either have a per application memory limit, but the stack will
still be able to grow and grow to this limit and then the program will crash
(i.e. the operating system will have to terminate it once the allowed
address space limit has been reached).

As you can see, there is a good reason to have a stack size limit in the
first place.  With only 128 process table entries and 2 GB per application
memory limit, this small program can consume 64 GB of memory (or swap
space)!   How would dynamic memory allocation help here? ;-)


    Thorsten


* Disclaimer: Don't run this program on a system you don't own. Some
administrators don't like such programs :-)

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message