This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Builtins and C++ and such
- From: Jason Merrill <jason at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>,"jsm28 at cam dot ac dot uk" <jsm28 at cam dot ac dot uk>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,"bkoz at redhat dot com" <bkoz at redhat dot com>
- Date: Tue, 19 Mar 2002 23:47:06 +0000
- Subject: Re: Builtins and C++ and such
- References: <Pine.LNX.4.33.0203191701200.605-100000@www.eyesopen.com>
>>>>> "Roger" == Roger Sayle <roger@eyesopen.com> writes:
>> Why? (Not meant to be a rhetorical question; I'm curious.)
>>
>> Certainly, __builtin_memcpy is necessary -- but why gunk to turn
>> memcpy into __builtin_memcpy? Isn't that something the library
>> headers can do for you, at least in C++ where you *had* to have
>> a declaration? Do we really care about people who manually write
>> the declaration themselves?
> Amongst the issues that I hope would be fixed by the solution that
> we decide upon is the ISO C++ requirement that #include <string.h>
> defines both "::memcpy" and "std::memcpy" (i.e. in both the std and
> global namespaces).
I feel pretty strongly that that should be handled by the library, not the
compiler. If the compiler sees a declaration in one namespace, it
shouldn't magically insert it into another namespace as well.
I'm amenable to providing compiler help in implementing the C header
shadowing stuff, but it should be something that's explicitly requested by
the library code. Nathan Myers' original strategy had one or two requested
extensions that seemed reasonable, though they haven't been implemented
yet.
Jason