Paul Eggert <[EMAIL PROTECTED]> writes:
> The check shouldn't depend on CFLAGS. That's too fragile, as bounds
> checking can be turned on by means other than CFLAGS. For example,
> the flag might be in CC, or gcc might be a shell script that invokes
> /bin/gcc -fbounded-pointers.
Agreed. All along I was thinking of doing something more reliable,
but didn't want to digress into that discussion yet. Suffice it to
say there will be some reliable way to test for presence of the BP
option.
> Also, surely trying twice for each function won't work in general.
> For example, suppose a library function is available only in
> non-bounded-pointers mode, and we are building in bounded-pointers
> mode. Under your proposal, it appears that `configure' would conclude
> that the function exists, but the program won't link.
I don't follow you. I think it works. We always compile with the BP
option. What changes is the signature of the dummy decl & call in the
tiny test program. If the function only exists in the non-BP library,
then it can't ever be found to exist by configure which does all
compiles in BP mode.
> A reliable way to catch this problem is to include the relevant system
> headers before mentioning the function. This is needed anyway for C99
> conformance, so the change should be made to autoconf regardless of
> what is decided for bounded-pointers support.
I agree that this is the correct way to go in principle, and it might
be the best accommodation that I can get from Alexandre. 8^)
How likely is it that such C99 changes will make it into autoconf, and
when?
> We shouldn't require users to convert configure.in as a prerequisite
> for using BPs.
>
> We're not talking about users or even installers, as they don't run
> autoconf. We're talking about maintainers, and we can expect more of
> them than we can of users.
OK. I agree. In general it will be a package's maintainer(s) who are
the first users of BPs on that package. BPs could be a nice
inducement to upgrade configure scripts for C99.
> There will be glitches in getting most nontrivial programs to work in
> bounded-pointers mode. They won't work out of the box. Fixing these
> glitches will require some (presumably minor) changes. One can think
> of the changes as `porting changes' to bounded-pointers hosts.
>
> It shouldn't be too much of a burden to ask maintainers to replace
> AC_CHECK_FUNC with AC_CHECK_FUNCTION along with all the other minor
> porting changes that they have to install anyway.
Yes, there are sometimes changes, and they are generally minor. I
needed no changes at all for textutils & fileutils, and only four
changes so far for gcc+cpp+fixincl. These are best cases since these
programs were already very well cared for. Crappy legacy code can
require *much* more work, especially if it recklessly uses
pointer/integer casts.
> Yes, can you please arrange for this? People who want bounds checking
> typically want interface checking too.
Yes. Sounds reasonable.
> > ... or casting its arguments to
> > pointers. So even if its signature contains no pointers, a function
> > can still be incompatible with code compiled with the other regime.
>
> Gcc does the right thing. If a function accepts an integer arg but is
> passed a pointer, gcc strips the bounds from the pointer and passes a
> single word, and issues a warning.
>
> Does this catch all instances of the problem? For example, what about
> the following features, or combinations of these features:
>
> * A function passed as a parameter from code expecting bounds checking
> to code that is not expecting it (or vice versa), where the function's
> signature has a pointer.
Yes. That's a type-checking violation.
> * A varargs function whose signature does not contain pointers, but
> which accepts pointers in the varying part of the argument list.
Yes. This is a bit shakier: it depends on the default boundedness
that is applies at the time the function's prototype decl is parsed.
If pointers are bounded when the decl is parsed, then pointer args
passed to it will be bounded, and unbounded otherwise.
> * __builtin_apply
Unknown.
> * union
Yes.
The general algorithm is this: All gcc tree nodes for types have a
two-bit bitfield called `pointer_depth'. A scalar has
pointer_depth=0. A pointer has pointer_depth equal to one plus the
pointer_depth of its referent type (e.g., pointer to scalar has
pointer_depth=1. Pointer to pointer to scalar has pointer_depth=2).
An aggregate type (struct/union/array) has pointer depth equal to the
maximum pointer_depth of its components. Functions types are
considered to be aggregates of their return type and arg types. All
pointer depths greater than 2 are represented as 2. The
pointer_depth=3 has a special meaning that applies only to varargs
lists. Also, all type nodes have a `bounded_flag' which says whether
this type's size or layout is altered by the presence of BPs. The
bounded_flag of an aggregate is the boolean `or' of the bounded_flag
values of its components. Further, the boundedness of a pointer is
handled like other cv-qualifiers, so that mismatches in boundedness in
multi-level pointers are caught by the type-checker.
All of this provides enough information to determine at compile time
if and how BP and non-BP code can mix, and how much of that mixing can
be facilitated at compile-time by automatically generating thunks to
translate between BP and non-BP interfaces. Right now, the
thunk-generation code is immature and really only useful for the
c-torture tests which are trivial programs.
In general, functions with pointer_depth=1 are eligible for
automatically generated thunks. Functions with pointer_depth=2 are
too complex for automatic thunks.
> It's OK if the __BP_ prefix is merely a convenience -- i.e. if it
> doesn't catch all instances of bounded-pointers mismatch, only most of
> the practical instances. (It would be nicer if it caught all
> instances, of course.)
It is intended to be airtight since it is such an important
convenience: it catches mismatches at link time that would otherwise
require much greater debugging cost to find at run time.
> At any rate, could you please check that the
> documentation accurately describes what the prefix catches?
Of course.
