Esthetics (or worse?) of Secure Pointers

[Greg McGary]

Chris Lattner <sabre@nondot.org> writes:

> Another alternative way to implement this (which would allow a single libc
> that contains both bounded pointer code and nonbounded pointer code to
> exist in the same library), would be to mangle function names, ala
> C++.  Of course you could do this really simply by simply prefixing all
> functions (C as well) with __BP_ or some such ugly thing.

I want to move in the opposite direction, and drop the __BP_ prefix,
since it complicates symbolic debugging, and I don't want to burden
gdb with hiding the prefix.  OTOH, the reason I introduced the prefix
in the first place remains valid: I wanted to catch unintentional
mixing of BP and non-BP code at link time, so as to prevent
much-more-painful-to-debug runtime incompatibilities.  Perhaps that
can be accomplished some other way.  Since we all agree that
compilation units will either be 100% or 0% BP, we needn't have a
mechanism that operates at the granularity of functions as the current
__BP_ prefix does.  We could introduce a special symbol that marks a
BP object (analogous to gcc2_compiled.), and make ld gripe if it sees
any mixing of BP and non-BP objects.

> This isn't a wonderful solution from a cleanliness standpoint, but it
> would make it "impossible" to accidentally mismatch code.  It would also
> make it possible to have a library with both bounded pointer and
> nonbounded pointer code linked into it, which would be nice.

The libs should remain separate just as they do for other multilibs.

Greg