Mail Archives: djgpp/2001/06/26/05:00:14
Graaagh the Mighty <invalid AT erehwon DOT invalid> wrote:
> On Mon, 25 Jun 2001 15:56:03 +0300 (IDT), Eli Zaretskii
> <eliz AT is DOT elta DOT co DOT il> 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.
- Raw text -