Pointer & array bounds checking (was Re: Code Generation)

[Per Bothner]

> There are satisfactory ways of preserving binary compatibility with
> fat pointers, so they are not "very inconvenient".

I don't buy it.

> Regarding (2), binary compatibility is not significant if all code
> (application, libraries, system-call interfaces) is compiled with BPs.
> A very cool goal is to build a completely BP'ed GNU/Linux system.

But for 90%+ of users *and* developers that is not going to be the
Linux system sitting on their desks, so it doesn't help them any.

> Rather than restricting fat pointers to be internal to functions only,
> it would be much better to broaden the use of fat pointers to entire
> subsystems, or entire applications--large collections of cooperating
> code that are all fat-pointer compatible.

But they will have to be able to call system libaries which you
don't want to or can't recompile.  And the linker cannot compensate
for incompatible structure sizes and offsets.

One option is for the compiler to recognize that certain structures
are passed to non-BP libraries, and compile thin-pointer code for
them.  But that is basically just a more sophisticated version of
what I am proposing:  The compiler still has to handle thin pointers
in external libraries, so why not start by implementing pointers,
and later add the optimizations to use fat pointers in more and
more places.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/