Mail Archives: djgpp-workers/1998/03/23/15:55:07
[...]
>
> >> and then call it if the appropriate crt0 flag is set?
> >
> >Or not call it if the appropriate crt0 flag is set. What should the default
> >be?
>
> That's actually a good question. It seems that the default should be to
> protect, just like the NULL page. But some perverse folks out there may well
> have written some interesting self-modifying code, and they'll complain when
> it suddenly breaks. Hmm.
I'd vote for write protect as the default, because
this is compatible with all UNIXes I have seen,
it does prevent stupid bugs and I think it is just as much worth it
as NULL pointer protection, so this is just another shade of the
"my code runs on Windows but not under CWSDPMI", but I still
think it should be the default.
Ciao
>
> >> Will `text' always be the first section, and will it always start at
> >> virtual address 0?
> >
> >Should be first, but starts at 0x1000 not 0.
> >
> >> I suppose this will cause some minimal code bloat, by forcing
> >> `__djgpp_set_page_attributes' to be linked, but AFAICT it's only about 2-300
> >> bytes.
> >
> >Yep, the problem is those 20 new features at 300 bytes each become noticeable.
> >But it will allow more rigorous checking and better code. Another idea which
> >I considered was to "no access" (like null page) the bottom page of the stack
> >which would catch many overruns. Lots of nice features which could be added...
>
> That *would* be a nice feature. It shouldn't take *much* more code to add
> it. But, OTOH, that's how Emacs got started... :)
>
> This is tricky. There's a fine line here between what the user wants, and
> what they need but won't admit to needing. The threads on the theme of "Why
> is Hello World 80K?" are ubiquitous, and some users won't want more just to
> help keep them from shooting themselves in the foot. ("My programs never
> have bugs!") Yet that's one of the main reasons to have protected mode. Hmm...
>
> The stack thing is a little inflationary also, since we could then say,
> "Well why not protect *two* pages and catch even more overruns?" "Why not
> three?" etc, etc.
>
> On the whole, however, I think bug-protection issues like this are a good
> idea. Not that DJGPP doesn't have more holes than a shotgunned swiss cheese
> already, of course. ;-)
>
> (Incidentally, when you unmap a page, does its memory get freed? I had an
> idea for a malloc-checker that would protect a page after each allocation,
> but if it stays allocated, that would be some HUGE memory overhead.)
>
> Nate Eldredge
> eldredge AT ap DOT net
>
>
>
>
Tom
******************************************************************
* Thomas Demmer * Phone : +49 234 700 6434 *
* Universitaetsstr. 150 * Fax : +49 234 709 4162 *
* Lehrstuhl fuer Stroemungsmechanik * *
* D-44780 Bochum * *
******************************************************************
* Email: demmer AT LStM DOT Ruhr-Uni-Bochum DOT De *
* WWW: http://www.lstm.ruhr-uni-bochum.de/~demmer *
******************************************************************
Kofsky's Law: You can never be too rich, too thin,
or have too much memory.
- Raw text -