From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Peculiar behavior of program. Date: 26 Jun 2001 08:50:25 GMT Organization: Aachen University of Technology (RWTH) Lines: 69 Message-ID: <9h9ich$jhe$1@nets3.rz.RWTH-Aachen.DE> References: <3b37e2d6 DOT 287121289 AT news DOT primus DOT ca> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 993545425 20014 137.226.32.75 (26 Jun 2001 08:50:25 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 26 Jun 2001 08:50:25 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Graaagh the Mighty wrote: > On Mon, 25 Jun 2001 15:56:03 +0300 (IDT), Eli Zaretskii > sat on a tribble, which squeaked: >>You should be safe all the way until you hit the stack bottom, i.e. use >>up all the 512KB of the default stack. > That's a lot. The worst-case recursion in the program would, however, > recurse over every pixel on a 1024x768 display, easily exceeding that. If so, your program has a very serious algorithm design problem, anyway, and no amount of ranting about how the runtime environment and DPMI server fail to notice the precise reason and tell you which line of your source you have to change to fix it is going to change that. That code was essentially broken before you typed in the first line of it. > OTOH, the worst case shouldn't happen except for seriously > pathological cases. If 768*1024 levels of recursion, or more, is your worst case, it's much more serious than "shouldn't happen". It *must* *never* happen, or your app will be toast. On just about every platform you may try it on, not just DJGPP. >>That would require to use a separate selector for the stack (because the >>stack is expand-down, and so needs a special segment setup for detecting >>stack overflows). This is possible, but has a serious problem: you >>cannot use -fomit-stack-pointer, because the EBP register will trigger a >>GPF if loaded with a value larger than the stack size. > That suggests to make such a scheme be used when code is compiled with > -g and not -fomit-frame-pointer. Can't be done. For starters, the usage of -fomit-frame-pointer and -g could be mixed, among the lots of .o files that together form your executable. Second, usage of the -fomit-frame-pointer option isn't recorded in the .o file, so neither the linker nor the runtime environment can even detect this fact, in order to be able to change behaviour according to it. Another reason which I think Eli forgot about: the truly separate stack only ever worked in the versions of DJGPP far ago that used VCPI instead of DPMI, IIRC. Those which didn't work inside Windows DOS boxes at all, since there, only DPMI is available. > You can't change DPMI, but you can extend it when CWSDPMI is used. It > is well worth considering it. Hmm... now, do I hear a volunteer speaking up, there? Feel free to extend it, if you feel up to it. >>I was talking about the code that gets linked into your program, not >>about CWSDPMI. The code in your program doesn't know what host it will >>run with, so it needs to work with all of them, which means playing by >>the rules. > Unless it has some way of identifying the host. Which it does. The > startup code can simply attempt to read from 0; CWSDPMI will trap this > while Windoze will not. That's too coarse a method, by a wide margin. Just because it supports proper NULL pointer protection doesn't mean the DPMI provider is CWSDPMI --- lots of other ones exist that don't share this lacking feature with Win9x's builtin DPMI services. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.