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

[Greg McGary]

Per Bothner <bothner@pacbell.net> writes:

> > There are satisfactory ways of preserving binary compatibility with
> > fat pointers, so they are not "very inconvenient".
> 
> I don't buy it.

Time will tell.  I have some experience mixing BP and non-BP code and
know firsthand that it can be convenient.  That doesn't mean that it
is always convenient.  Much depends on where one draws the line that
partitions BP from non-BP code.  Library APIs that exchange pointers
within aggregates will need attention.

> > 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.

One need not run wall-to-wall BPs in order to use them for one's
development work.  If one installs BP-compiled versions of common
libraries, then one can build 100% BP applications, regardless of
whether the kernel, and utilities were compiled with BPs.

> > 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.

Only those interfaces that exchange pointer-containing aggregates need
attention.  For libc, there are only a handful of these, and they can
either be explicitly declared as unbounded, or a more elaborate thunk
can translate.  I expect that you have specific libraries in mind that
won't work well when compiled non-BP and mixed with BP code.  In my
experience, libc and Xlib do work well as non-BP libraries mixed with
BPs.  Of course, every applications is different and YMMV.  What
libraries do you see as problematic?

> One option is for the compiler to recognize that certain structures
> are passed to non-BP libraries, and compile thin-pointer code for
> them.

Or, at least issue a diagnostic so the programmer can choose how to
resolve the conflict.

> 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 [thin] pointers,
> and later add the optimizations to use fat pointers in more and
> more places.

I'd rather make fat pointers the default and gradually increase the
sophistication of the toolchain to automatically handle more and more
code-mixing wrinkles.  Right now, it is possible to overcome all
mixing troubles by explicitly qualifying individual decls, groups of
decls, all decls within named include files, or all decls within named
include file hierarchies.  Explicit qualification of non-BP decls is a
viable approach as long as number of places that it must be done is
small.  If many such qualifications are required, then I must agree
that it's inconvenient.

Greg