"Numerical Recipes in C" is nonportable code

[Craig Jackson]

In article <1429 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>In article <640 at drilex.UUCP>, dricej at drilex.UUCP (Craig Jackson) writes:
>> * Note that putting the protection in the compiler was also an idea
>> of Per Brinch-Hansen's in the 1970s, with Concurrent Pascal.  Burroughs
>> had been doing it for many years, even then.
>
>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...

Two things stop this:

1. There's no way to 'say it'; see below.

2. There is a tag field on each word of memory.  Data has a tag of 0 or 2;
code has a tag of 3.  It is the responsibility of the compiler to make sure
that a user program cannot set its own tags.  Only the operator can turn
a program into a compiler, and only a compiler can create an object program.

(There are, of course, holes for people with super-user-like privileges.
Just like Unix.)

>* this may involve such things as passing a pointer to an array to a
>function that's declared that argument as a pointer to a function, or
>even by writing the array out as a file and executing it... I can't see
>how you could write a valid 'C' compiler that wouldn't let you violate
>this protection.

Another feature of this system is a type-checking linker.  All functions
must agree in number of arguments and type of arguments with their calls.
The linker, called the binder on the A-series, enforces this.  (This makes
varargs be a pain in the behind, BTW.  One reason why A-series C most likely
will not fully use the hardware, and therefore be a slow, undesirable
language.  Much like their PL/I.)

>Peter da Silva  `-_-'  Ferranti International Controls Corporation.


-- 
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson