Alexandre Oliva <[EMAIL PROTECTED]> writes:
> It's definitely not, and I had intended to make this clear in my
> reply. But proponents of weird features may point at
> bounded-pointers, which *they* might consider weird, and use it to
> convince us to accept their weird feature. Of course, we may be able
> to decline their proposals with other arguments, but they may feel
> we're not being fair.
If I read you correctly, we can slip this in more easily if we keep
the script growth to a minimum. I think that can probably be done
by putting a loop around the test so we go once without the prefix
and once with it. Does that sound reasonable?
> I'm talking about generating the thunk at the time you compile the BP
> function, not when you compile its user. So you'd be able to use BP
> functions even though your compiler doesn't support BPs, or you're not
> using the switch that enables them.
That makes some sense, but potentially opens a large can of worms. In
general, people won't want a BP library unless they're debugging, and
in that case they'll want BPs for the code that uses the library. The
only reason I can think of for supporting both BP and non-BP
interfaces to a library is where you have BP application and a non-BP
library "A" that both use library "B". The BP application will want
B's BP interface but A will want B's non-BP interface. However, this
situation might not work at all if B's interface includes data
structures that contain pointers. In general, BPs work best (if at
all) in situations where you have 100% source code availability. This
isn't like Purify where you can patch object code. Actually, I'm sure
RMS would consider that a feature of BPs in gcc: its effectiveness is
limited by the presence of code for which source is unavailable.
Anyway, even if we can generate a complete set of non-BP thunks that
are packaged with a BP library, I don't want to rely on that feature
to make autoconf work with BPs. If I can come up with a modified
AC_CHECK_FUNCS that doesn't bloat the configure script much (can you
give me a target overhead %?) and is otherwise well-engineered, will
you accept it?
Greg
