"Numerical Recipes in C" is nonportable code
Craig Jackson
dricej at drilex.UUCP
Sun Sep 11 09:42:49 AEST 1988
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
More information about the Comp.lang.c
mailing list