Date: Sun, 25 Apr 1999 16:23:56 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Randy Sorensen <randy AT idcomm DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Locking DJGPP Code and Data (repost)
In-Reply-To: <37224964.0@mindmeld.idcomm.com>
Message-ID: <Pine.SUN.3.91.990425161737.26701F-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sat, 24 Apr 1999, Randy Sorensen wrote:

> Is there some good reason why the developers of GCC for DOS (DJ, and others)
> don't implement a better system?

You cannot implement a ``better system''.  The problem is that it is next 
to impossible to lock code of a C function, because there's no way of 
knowing the size of the code.  Since the DJGPP project didn't write the 
compiler, only ported it, we need to live with the compiler's limitations.

> How else are you supposed to find the size of a function?

You need to write your function in assembly, then you have an easy way 
of computing its size. 

Alternatively, simply lock everything by using the bit in the 
__crt0_startup_flags variable, as the FAQ suggests.  Then everything is 
locked.

> So, the code I posted wouldn't lock the variables... but the code would be
> locked, right?

It's the other way around: the data is easy to lock, but the code and the 
stack (i.e. automatic variables) are not.