C++ PATCH: PR 9924

[Roger Sayle]

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.  As GCC gains more and
more knowledge of the standard library functions, the probability that
names will clash with user identifiers increases.

For example, if the user writes 'extern "C" int qsort(void) throw (bar);'
g++ will consider all calls as unable to throw an exception.  This bug
is fundamental in the current code, which can't be disabled with either
-ffree-standing or -fno-builtin-qsort.  The code as written even fails
to consider std::qsort as nothrow.

As an example of C++'s brokeness when handling builtins, nothrow_libfn_p
makes a good example.

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.

The reason there are no high-priority PRs asscociated with nothrow_libfn_p
is that if in C++ we accidentally consider a library shadowing function
nothrow, no one would ever notice.  But as soon as you try extending it to
va_list processig, printf format checking, errno handling, constness and
purity etc... it would become apparent very quickly that it just isn't as
safe as the tried-and-tested builtins.def mechanism.



> > Nobody's even commented on my suggestion of using the PCH machinery
> > to efficiently preload the builtins DECLs from iso90.gch, iso99.gch
> > or a g++.gch.
>
> I think that the PCH machinery only supports a single monolithic PCH per
> compile, so such a scheme would preclude, say, a libstdc++ PCH.

That would be a fundamental limitation.  Is this really the case with
the current design?


Roger
--