From: Greg McGary <[EMAIL PROTECTED]>
Date: 24 Jul 2000 02:18:59 -0700
> 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.
Here are more details about the scenario that I was thinking of.
Suppose the actual function's signature is `char *F (void);' but F
exists only in the non-BP library. 'configure' will compile a
declaration `char F ();' in BP mode. My understanding of your scheme
is that this declaration will match the non-BP F since `char F ();'
has no pointers so no __BP_ string is prefixed to it.
Now, suppose the actual program includes a standard header that
declares F properly, or declares F properly itself if there is no such
standard header. (This is a common pattern in GNU applications.)
Then the actual program won't link, even though 'configure' found F.
As before, the rest of this message is more about bounds checking than
about autoconf, but here goes anyway. (Maybe you can save time by
pointing me to the documenation. :-)
> * 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.
Sorry, when I wrote 'expecting bounds checking' I meant 'compiled in
BP mode', not 'declared with a signature that contains a pointer'.
It's not a type violation to invoke non-BP code from BP code.
I worry that the above scenario is not caught by the __BP_ prefix.
Also, suppose F's signature contains a pointer, and F is passed to
another function whose formal parameter F' has signature that is not
prototyped and does not contain a pointer. Conversely, F might be
non-prototyped (and without a pointer), but F' might be prototyped
(and with a pointer). These are not type-checking violations, but I
can see where they might cause problems if __BP_ functions are invoked
differently from non-__BP_ functions.
> * 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.
This seems to defeat the __BP_ prefix's intended purpose for this
particular case. Wouldn't it be simpler and more reliable to prefix
__BP_ to all varargs functions, even those without pointer types?
That way, you can safely always pass bounded pointers to varargs
functions.
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).
You don't mention pointers to functions. Presumably, they have depth
equal to that of the function type. It doesn't seem right for them to
have depth one greater than that of the function type, as one can't
apply arithmetic to a pointer to a function.
Also, you don't mention void *. If I convert a pointer to void * and
back, do I lose its bounds?
Functions types are considered to be aggregates of their return
type and arg types.
except that varargs functions have depth 2 or 3?
Also, what is the depth of a non-prototyped function type? The same
as varargs? That is the only value that makes sense to me, but it
doesn't seem to agree with some of the other things you wrote.
(I'm a bit lost here.)
> * __builtin_apply
Unknown.
Perhaps it's best to reject programs using the __builtin_apply stuff
when compiling in BP mode, until the issue is understood better.
