PATCH: change splay_tree_key & splay_tree_value types to void*

Mark Mitchell
Tue Aug 29 21:32:00 GMT 2000

>>>>> "Greg" == Greg McGary <> writes:

    Greg> It's not so easy.  Pass integers to strcmp and they're
    Greg> promoted to bounded pointers--that part works--but the
    Greg> bounds that are attached in this case are [0..0), and the
    Greg> checks inside strcmp fail.  I'm loath to attach maximally
    Greg> permissive bounds of [0, ~0) to integers in the
    int-> BP promotion because that seriously undermines the ability
    int-> of BPs
    Greg> to catch bugs.

I'm glad to see you working on this bounded-pointer stuff.  I don't
know if I've mentioned it before, but I did a lot of work on run-time
error-checking tools at CenterLine.  I'm going to love using your

I would suggest you *do* go with the permissive thing here, unless the
user specifically switches on a maximum paranoia flag.  The biggest
problem with our error-checkers was always that they found too many
almost bugs -- even when we tried to make them really, really lenient.
We found, after years of experimenting, that the vast majority of
users really only want to know about things that are disastrous, even
of those that wanted to use an error-checking tool.

For example, this K&R code:

  foo_p(s) { 
    return strcmp (s, "foo") == 0;

will otherwise likely give a false positive.

Another strategy would be to use a special bounds token that says
"integer converted to pointer" and interpret it strictly in most
places, but leniently inside the string functions.  I'm actually
serious about this -- ugly as it seems.  I think it might be the best
strategy.  Special-casing certain library functions was definitely
done in CenterLine's tools.

It's hard to do source-assisted run-time error-checking in programs
that aren't typesafe -- and programs that cast integers to pointers
and back are included in that category.  For maximum win, our "pointer
descriptors" (which contained not only bound information, but also
type information) were recoverable -- if there was no descriptor
available for a pointer, and you had certain switches on, the run-time
system (which also controlled malloc, in order to do leak-detection,
etc.) would go looking for a pointer descriptor by using the pointers

I guess my overall point is that I bet this problem will exist in user
packages.  splay-tree.h isn't really part of GCC -- it's just a
library.  If that library causes false positives then so will other
libraries; I don't think splay-tree.h is that unique a beast.

Mark Mitchell         
CodeSourcery, LLC     

More information about the Gcc-patches mailing list