Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: "Numerical Recipes in C" is nonport
Message-ID: <225800065@uxe.cso.uiuc.edu>
Date: 9 Sep 88 13:39:00 GMT
References: <5162@hoptoad.uucp>
Lines: 26
Nf-ID: #R:hoptoad.uucp:5162:uxe.cso.uiuc.edu:225800065:000:1253
Nf-From: uxe.cso.uiuc.edu!mcdonald    Sep  9 08:39:00 1988



>What's to stop you from doing the following:

>	Generate code in an array.
>	Jump to the beginning of the array. *

>Now you've blown the protection. You can do anything. I hope this isn't a
>multiuser machine...
It is certainly possible to design machine\compiler combinations that
prevent this. I call them "totalitarian " or "Stalin" operating systems.
Apparently ANSI C does not prohibit this behaviour: a fatal flaw
in the ANSI standard. IF you can't do this, an entire class of programs
becomes absolutely impossible: incremental compilers. It would prohibit
a Turbo C or Quick C clone, for example. All of my programs I have designed
for teaching chemistry and physics wouldn't work.  It is even possible
to design an operating system so that is is impossible (inside it of course)
to write compilers: there is some magic cookie necessary to make
an executable file, and no compiler or assembler allows setting such 
cookie *. VMS makes it rather difficult to set such a thing (but 
possible). Does the Unisys A series REALLY make it all that impossible?
If so, maybe that is why no one has ever heard of them!

Doug McDonald

* I mean that the compiler can make an executable, but that you can't
write a program that will make an executable.