"Numerical Recipes in C" is nonport

Craig Jackson dricej at drilex.UUCP
Sun Sep 11 09:25:05 AEST 1988


In article <225800063 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:

[Although there is no attribution, I wrote the >> stuff.  CEJ]
>>There exist machines whose protection philosophy is to prevent you from
>>even thinking something illegal.  In particular, on the Unisys A-series,
>>the compiler must implement all memory addressing protection--there is
>>no kernel/user state protection on memory.*  A program cannot be allowed
>>to form an invalid address, as there is nothing to stop it from using it,
>>and nothing in the hardware to stop you from stomping on another user
>>if you do.  Therefore, the compiler and the operating system would be
>>written so as to cause an interrupt if computing 'b - 1' were attempted.
>
>>Note that there is no C compiler for the A-series today, although one is
>>rumored.
>This seems logically inconsistent. You say that on the Unisys A-series
>that the problem is in the compiler. But then you say there is no
>C compiler. If the problem exists in other language compilers,
>simply leave it out of C! Simply write the compiler so that it doesn't
>check pointers. (If it did do that, wouldn't it be a horrendous time
>penalty? Every time you said "pointer++" it would have to check
>bounds, unless the pointer were declared the non-existant "noalias".)

You don't completely understand.  The problem is not in the compiler,
the 'problem' is in the architecture that leaves things up to the compiler
to check.  Theoretically the system could be a little faster by not doing
as many security checks at run time; in reality, they don't save any logic,
I believe.

The upshot of this is that if you wrote a compiler that allowed undisciplined
pointer operations, the system would be about as safe as MS-DOS.

The nice thing about the hardware is that "pointer++" is checked by the
hardware, assuming that the arrays are set up in the normal manner.  There's
a special 'add to pointer' instruction, which checks the tags on memory.
There's another instruction to 'subtract from pointer', which is going
to be used for 'int b[10];int *bb = b - 1;'.  This instruction, in
attempting to move the pointer down from the beginning of the array,
would hit a word with an illegal tag and cause an interrupt.

>What about assembly language? What is to stop things from 
>happening there with out of bounds pointers?

There is no assembler for the A-series.  Normal programs are written in
ALGOL, COBOL, FORTRAN, PASCAL, or PL/I.  The operating system, and certain
operating systems extensions, are written in an extended ALGOL called NEWP.
NEWP cannot be used to write normal user programs, and NEWP libraries (which
are sort of an operating system extension) must be blessed by the operator
before they are executed.

>Doug McDonald

As a further note, I believe that one reason why A-series C might not
use the hardware stack and hardware pointers in a normal manner is
varargs.  What can be done about a system which *must* check argument
count & type before execution?
-- 
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson



More information about the Comp.lang.c mailing list