Mail Archives: djgpp/2001/06/28/14:52:00
On 26 Jun 2001 08:50:25 GMT, Hans-Bernhard Broeker
<broeker AT physik DOT rwth-aachen DOT de> sat on a tribble, which squeaked:
>> 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.
Quicksort behaves poorly for pathological inputs, but people still use
it. (And there's an implementation in libc.) Algorithms with bad
run-time performance for pathological cases should still be usable
without risking an OS crash! Obviously. The worst that should occur is
that it dies gracefully with an allocation failure message, IMO.
>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.
There's a difference, however, between it dying with an allocation
failure of some sort and blowing up like a nuclear device, with heavy
civilian casualties.
>> 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...
Sure. That's why I said it should do the extra debugging only when -g
is used and -fomit-frame-pointer, moreover, is not.
>...among the lots of .o files that together form your executable.
No problem. The scope of the debugging aid would be limited to the .o
files that met the above criterion. Which would always include the
ones that were suspected of being the problem.
>Second, usage of the -fomit-frame-pointer option isn't recorded in
>the .o file.
And it's the compiler, that writes the .o file, so the compiler
writers can't claim that that particular obstacle is a circumstance
beyond their control. Next objection, please?
>Hmm... now, do I hear a volunteer speaking up, there? Feel free to
>extend it, if you feel up to it.
I don't have the technical expertise, but these kinds of problems and
debugging nightmares will eventually bite any serious programmer in
the butt with probability 1, so someone who does would eventually
benefit by doing so...
>> 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.
What the heck is that supposed to mean? In practise, people coding
DJGPP stuff use exactly two DPMI hosts (or just one of them): CWSDPMI
and Windoze. (What others *are* there, anyway???)
Also, the point I intended is more general. Host detection is
possible, and can undoubtedly be made very easy if you can alter both
the host and the code that will want to detect it. In the case of
DJGPP these conditions are met, since the compiler port and CWSDPMI
are both open source and developed together more-or-less as a unit.
--
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 -