Re: bounds-check intentionally undocumented?

[Greg McGary <gkm at eng dot ascend dot com>]

Robert Lipe <robertl@sco.com> writes:

> > job under control, which is to persuade gcc and glibc to manipulate
> > BPs in all contexts: pass them as function args, return them as
> 
> Is this also available on systems where replacing system libraries isn't
> an option?

[ copied to gcc.gnu.org, since your question is of general interest ]

In theory, yes.  In practice, it's a bloody nuisance to have an
unbounded libc.

The new BP feature set offers two ways to mix BP and non-BP code:

(1) explicitly qualify decls of library functions as unbounded, which
    can be done three ways:

(1a) Supply __bounded or __unbounded type qualifiers to pointer
     decls: e.g., char *__unbounded *__unbounded argv.

(1b) Supply bounded or unbounded attribute to decl:
     e.g., void *foo (char *, int, void *) __attribute__ ((unbounded));
     The attribute can have an optional "depth":
     e.g., void *foo (char ***, int, void *) __attribute__ ((unbounded (2)));
     this means to force unboundedness for the first two levels of
     indirection  The first arg is effectively
     char *__bounded *__unbounded *__unbounded when compiled with
     -fbounded-pointers.  A depth of -1 is effectively infinite.

(1c) Surround code with __bounded { ... } or __unbounded { ... } to
     override the ambient boundedness.  This is something like the C++
     extern "C" { ... } construct.

(2) provide thunks to translate between bounded application code and
    unbounded libraries.  These can be written by hand (yuck), or gcc
    can generate them automatically when it appears to be safe to do
    so.  I haven't done enough with this yet to know how much it might
    help with libc.

A couple years ago with an earlier incarnation of BPs in gcc-2.7.2, I
had good success with building X11 applications with BPs for the app
and libc code, and non-BPs for the X libs.  However, I have had many
headaches trying to mix BP application code with non-BP libc.  A naive
strategy would be to write header-file wrappers like so:

	<prefix>/unbounded-include/stdio.h:

	__unbounded {
	#include_next <stdio.h>
	}

then arrange to pass -I<prefix>/unbounded-include to gcc.

The problem is that because of the long and tortuous history of C and
libc, there is significant variation in the contents of standard
headers from OS to OS.  Portable applications therefore declare many
standard functions themselves in order to make up for deficiencies in
the headers (e.g., app declares `int fflush(FILE*);' just case).  With
the wrapper above, if fflush is declared in stdio.h, gcc first sees
a decl with unbounded FILE*, then when it sees the app's decl with
bounded FILE* and chokes on the conflicting decl.  Multiply that
scenario by 100 and you get the picture for a large program.

These difficulties could be overcome with considerable work on the app
code.  One way to accommodate non-BP libc for apps that use
automake/autoconf would be to add stuff that identifies the origin of
each libc function (either from the non-BP libc or from a BP
replacement function packaged with the application), and generates
replacement header files or header-file wrappers to manipulate the
decls to match the binary.  Another approach is to provide a complete
set of thunks for a non-BP libc that adds a BP veneer (gcc's
thunk-generator could be used to make many of these).  Both sound like
a lot of work.  A third approach is to dump the proprietary libc and
use glibc (1/2 8^).

OTOH, non-BP X11 mixes well with BP applications because compared to
libc, X11 headers are much more uniform and complete, so that the
wrapper trick works well.  In general, I expect that other libraries
that have complete sets of headers, along with application code that
uses those headers rather than explicitly declaring library facilities
can also mix well.

Greg