delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2001/07/04/13:00:11

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: <Pine DOT SUN DOT 3 DOT 91 DOT 1010701113040 DOT 20826K-100000 AT is>
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
<eliz AT is DOT elta DOT co DOT il> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019