From: Greg McGary <[EMAIL PROTECTED]>
Date: 21 Jul 2000 13:36:01 -0700
The backward-compatible AC_CHECK_FUNC should also work with BPs as
per my second suggestion (try once with return type `char' and again
with return type `char *' if `-fbounded-pointers' is in CFLAGS).
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.
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.
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.
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.
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.
The rest of this message is more about bounds checking than about
autoconf, but here goes anyway....
> I don't see how this can work in general. A function can access data
> via other means, e.g. external pointers
As for external pointers, it works as well as C++ typesafe linkage,
which also mangles only function names. It makes sense to prefix data
names as well to close that hole.
Yes, can you please arrange for this? People who want bounds checking
typically want interface checking too.
> ... 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.
* A varargs function whose signature does not contain pointers, but
which accepts pointers in the varying part of the argument list.
* __builtin_apply
* union
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.) At any rate, could you please check that the
documentation accurately describes what the prefix catches?
