Path: utzoo!attcan!uunet!husc6!bloom-beacon!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.lang.c
Subject: Re: "Numerical Recipes in C" is nonportable code
Message-ID: <12094@oberon.USC.EDU>
Date: 10 Sep 88 17:51:56 GMT
References: <664@lindy.Stanford.EDU> <6758@megaron.arizona.edu> <718@gtx.com> <13454@mimsy.UUCP> <1450@ficc.uu.net>
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 27

In article <1450@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <13454@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
>> In article <1429@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>> -What's to stop you from doing the following:
>> -	Generate code in an array.
>> -	Jump to the beginning of the array. *

Decent memory protection.  (There are those of us who believe that
executable and writable memory should be mutually exclusive.  (with a
provision to change from one to the other.))

>So what's to stop me from writing out a load module and subverting
>the protection mechanism, as I noted in my (deleted) footnote?

The same type of protection mechinism that makes it impossible
(or hopefully at least difficult) to alter other users files.
Writing out executalbe files may be considered a priviliged
function reserved to compilers.

(Please note I am not saying that I think that compilers are the proper
place to enforce system security, just that portably written code shouldn't
have undue hardship running on such a machine.)
-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request