From: invalid AT erehwon DOT invalid (Graaagh the Mighty) Newsgroups: comp.os.msdos.djgpp Subject: Re: CWSDPMI/DJGPP integration [was Re: Peculiar behavior of program.] Organization: Low Charisma Anonymous Message-ID: <3b434a45.81645309@news.primus.ca> References: X-Newsreader: Forte Free Agent 1.11/32.235 Lines: 46 Date: Wed, 04 Jul 2001 16:59:22 GMT NNTP-Posting-Host: 207.176.153.167 X-Complaints-To: news AT primus DOT ca X-Trace: news1.tor.primus.ca 994265839 207.176.153.167 (Wed, 04 Jul 2001 12:57:19 EDT) NNTP-Posting-Date: Wed, 04 Jul 2001 12:57:19 EDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Sun, 1 Jul 2001 11:30:52 +0300 (IDT), Eli Zaretskii sat on a tribble, which squeaked: >The number of cases I've seen where stack overflow _could_ be >caught--those with very deep recursion--is so small that it could be >considered nonexistent. I myself only had 1 such case in the last 10 >years (a naive implementation of flood-fill)... Very naive, it would seem. My latest code does a boundary tracing and flood-filling thing. Wherever I've seen this described, it supposedly requires maintaining a list, stack, or queue, or being recursive. Mine seems to work and it's just iterative -- a few nested for and while loops. Even the floodfill part, because the floodfill region has a nice "double-skinned" property as the boundary following generates it. There isn't a list, stack, queue, or recursive function in sight, and it seems to work perfectly even with very hairy boundaries to follow. (And you know how hairy the M-set can get.) >and the number of such >problems reported here is so insignificant that I don't remember >whether I've ever seen one. Well, it seems quite possible that you saw one a couple of weeks ago. >There used to be a problem with GCC compiling complex code (GCC uses >alloca extensively, or at least used to use it). We enlarged the >run-time stack of DJGPP programs to 512KB in response to that (and I >think the compiler is stub-edited to even larger stack in latest >ports), and those problems were never heard of since then. The compiler should probably be malloc'ing these things. Giving it a large stack is IMO a kluge, even if it "works" -- someday, someone will come along with a (admittedly probably badly-written and naive) program that consists of a 40,000 line "main" function, and complain in here when gcc blows up. Release versions of stuff should, where possible, be coded for the ages -- the most pathological user input you can imagine is inevitable, given enough time and enough copies distributed. -- Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980 "There's nobody getting rich writing software that I know of." -- 1980 "This antitrust thing will blow over." -- 1998 Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.