C++ PATCH: PR 9924

[Jason Merrill]

Hmm, it seems that I never sent this.  Oops.

On Thu, 13 Mar 2003 13:55:22 -0700 (MST), Roger Sayle <roger@www.eyesopen.com> wrote:

> On Thu, 13 Mar 2003, Jason Merrill wrote:
>> > Its not that I disagree with a strategy that recognizes declarations
>> > as they're defined, its just that's no-one's written or even proposed
>> > a workable solution along those lines.
>>
>> When we were discussing implementation before your overhaul, I advocated
>> extending the nothrow_libfn_p mechanism to cover all built-in knowledge of
>> C library functions.
>
> The major problem with nothrow_libfn_p is that it has no conception of
> the expected type associated with the identifier.

For extern "C" functions, it doesn't need to, since they must be unique.

> As GCC gains more and more knowledge of the standard library functions,
> the probability that names will clash with user identifiers increases.

The names affected by nothrow_libfn_p are reserved to the implementation.
Users aren't allowed to clash with them.  If you redefine a standard
library function, you need to obey the same constraints as the library
itself does.

> For example, if the user writes 'extern "C" int qsort(void) throw (bar);'
> g++ will consider all calls as unable to throw an exception.

Well, not actually for qsort, but for most other C library functions this
is true, because the standard says that g++ can do that.

> This bug is fundamental in the current code, which can't be disabled with
> either -ffree-standing or -fno-builtin-qsort.

OK, that's a bug.  It should obey those flags.

> The code as written even fails to consider std::qsort as nothrow.

That's because it isn't; you could pass it a comparison function which
throws.

> One of the reasons for moving nothrow_libfn_p, default_attributes and
> special_function_p to the builtins.def framework is that we can associate
> the identifier (including namespaces), the type and the attributes in
> a single place, and only use/apply them when they're consistent.

I agree that we should handle all these things in a single place.  I just
don't think that predeclaring them is the right way to do it.  In another
message, you mentioned wanting to eventually optimize STL member functions,
which clearly demands a different approach.

I'm not saying that you should have done something else instead of the
cleanup work that you did, but I still think that future evolution of this
support needs to work differently.

Jason