Path: csiph.com!1.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bob Eager Newsgroups: alt.folklore.computers,comp.sys.raspberry-pi Subject: Re: S/360 stacks, was self-modifying code, Is it a lost cause? Date: 6 Jul 2016 07:14:06 GMT Lines: 63 Message-ID: References: <1107158795.489361340.954697.peter_flass-yahoo.com@news.eternal-september.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net ZnZYl2Vl6fU3MIWMmgenAAdTTml41vmZ6i2qM1YbPulb49EN0N Cancel-Lock: sha1:vl2yhuVXy07qNiGBnaxVtyvFnuM= User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Xref: csiph.com alt.folklore.computers:166749 comp.sys.raspberry-pi:12578 On Tue, 05 Jul 2016 22:36:24 -0400, Dan Espen wrote: > Bob Eager writes: > >> On Tue, 05 Jul 2016 15:32:37 -0400, Dan Espen wrote: >> >>> Bob Eager writes: >>> >>>> On Tue, 05 Jul 2016 14:05:48 -0400, Dan Espen wrote: >>>> >>>>> Rob writes: >>>>> >>>>>> Dan Espen wrote: >>>>>>> It always seemed very odd to me, that when you write C code, >>>>>>> you're always told to always check the malloc() return code. >>>>>>> Yet, calling a subroutine needs main storage and the language >>>>>>> provides no way to check a return code for that. >>>>>>> I'm not sure if it raises a signal. >>>>>> >>>>>> This is implementation (mostly OS) dependant. Usually there is a >>>>>> signal for stack overflow, but it often is the generic signal for >>>>>> invalid memory accessed (SIGSEGV in Unix/Linux). >>>>> >>>>> Which leaves you no way to programmaticly detect the overflow. >>>>> The end user could add memory to the job if he got an informative >>>>> message. >>>>> >>>>> It's somewhat ironic, you put all that coding in for malloc failure >>>>> and end up being unable to detect stack allocation failure. >>>> >>>> In practice, a program would have to be *very* badly coded to run out >>>> of stack. Most modern stack-based systems use a stack that runs down >>>> from the top of virtualy memory, and it's extended automatically if >>>> one reaches the end of it. >>>> >>>> Yes, 'infinite' recursion will use it all up, but we are usually >>>> talking a gigabyte or two even on a 32 bit system. >>> >>> On z/Series, the stack and heap come from the same pool. >>> The limit is on total storage used, not one limit for heap, another >>> for stack as found on unix type systems. >>> >>> So, you can use up all the storage with malloc, but eventually fail on >>> a stack request. >>> >>> (At least in theory.) >> >> The stack and heap come from the same pool on most systems. The stack >> grows down, the heap grows up. > > Yes, but Linux seems to have separate limits for the stack and heap as > evidenced by ulimit output. And those limits are flexible and can be turned off. The stack limit is usually high enough that only poor programs will ever hit it. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org