Alexandre Oliva <[EMAIL PROTECTED]> writes:
> This sounds reasonably reasonable :-), but I wonder if people wouldn't
> complain about the additional seldom-used code in the configure
> script.
Do people complain about such things? I expect that most just
run the script without ever looking inside or noticing its size.
> Wouldn't it be easier if you just supplied an alternative
> definition of AC_CHECK_FUNC, to be used by people using the bounded
> pointers feature to re-generate their `configure' scripts?
I want to keep the barriers to using BPs as low as possible so
that people will be more likely to use them. Requiring users
to regenerate configure scripts seems too much of a burden, especially
if we're only doing it to satisfy .001% of the world that has an
aesthetic preference for configure scripts that are as small as
possible and contain no infrequently used code.
> My fear is that, as soon as we start to accommodate not-so-common
> features in standard autoconf, we may lose our argument against
> supporting really weird stuff that shows up every now and then.
It all boils down to whether you consider bounds checking to be a
"really weird" feature. I hope it will become a first-class feature
which deserves full toolchain support.
> Another possibility that comes to mind is to have -fbounded-pointers
> generate *also* a naked-pointers version of a function, without the
> __BP_ prefix, that turns naked pointers into fat pointers and calls
> the __BP_ version, then does the converse on any returned pointers.
> This would automatically solve autoconf's problem, because autoconf
> would find the functions it's looking for.
The problem is that gcc doesn't know that the function being tested
has pointers, so it must assume that all functions potentially have
pointers and generate a thunk. gcc certainly shouldn't behave like
this for normal compilation, so it must be an option. If it's an
option, then it's a configuration-time-only option, and we're now back
to being unable to configure with the same compiler options as we
build. At minimum you would need to teach configure about this
special option so that it could add it to CFLAGS if
`-fbounded-pointers' is present.
Even so, I still don't understand how this could work. This is what I
think you're suggesting: The test program calls foo in order to test
that a library supplies a definition. On the chance that foo might be
present as __BP_foo, gcc automatically generates a thunk named foo
that calls __BP_foo. If foo is really defined as __BP_foo, you win.
If foo is really just foo, you now have an overriding definition of
foo which contains an undefined reference to __BP_foo. Am I missing
something?
Greg
