From: "Tom Demmer" <DEMMER AT brain1 DOT lstm DOT ruhr-uni-bochum DOT de>
Organization:  Lehrstuhl Stroemungsmechanik, RUB
To: Nate Eldredge <eldredge AT ap DOT net>, cssl AT geocities DOT com,
        djgpp-workers AT delorie DOT com
Date:          Mon, 23 Mar 1998 21:14:06 GMT-1
MIME-Version:  1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:       Re: Can the text section be made read-only?
Reply-to: Demmer AT lstm DOT ruhr-uni-bochum DOT de
Message-ID: <563A9D978C7@brain1.lstm.ruhr-uni-bochum.de>
Precedence: bulk

[...]
> 
> >> 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.