This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: header, directory, shadow status
On Thu, Oct 12, 2000 at 01:25:47PM -0700, Benjamin Kosnik wrote:
>
>
> On Wed, 11 Oct 2000, Nathan Myers wrote:
> > Are you using Zack's gcc patches to keep standard ("builtin"?) types
> > un-namespace-mangled, when mangled into function names?
Sorry, that was Martin's patch, referenced below.
> huh? what patch? I know Brent has been working on this ...
It's not surprising that you are having trouble with size_t et alia,
if you're not using Martin's patch. It was noted in the original docs
that a working shadow header system depends on such a gcc feature.
Despite that Martin disagreed with the assertion, he wrote the code.
If it does the job it probably should be incorporated into the
mainline gcc.
Martin's patch:
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00553.html
Most recent discussion (in reverse chronological order):
http://sources.redhat.com/ml/libstdc++/2000-q2/msg00080.html
http://sources.redhat.com/ml/libstdc++/2000-q2/msg00077.html
http://sources.redhat.com/ml/libstdc++/2000-q2/msg00076.html
http://sources.redhat.com/ml/libstdc++/2000-q2/msg00059.html
This from the libstdc++ document, DESIGN:
A correct conforming definition of C header names based on underlying
C library headers, and practical linking of conforming namespaced
customer code with third-party C libraries depends ultimately on
an ABI change, allowing namespaced C type names to be mangled into
type names as if they were global, somewhat as C function names in a
namespace, or C++ global variable names, are left unmangled. Perhaps
another "extern" mode, such as 'extern "C-global"' would be an
appropriate place for such type definitions. Such a type would
affect mangling as follows:
namespace A {
struct X {};
extern "C-global" { // or maybe just 'extern "C"'
struct Y {};
};
}
void f(A::X*); // mangles to f__FPQ21A1X
void f(A::Y*); // mangles to f__FP1Y
(It may be that this is really the appropriate semantics for regular
'extern "C"', and 'extern "C-global"', as an extension, would not be
necessary.) This would allow functions declared in non-standard C headers
(and thus fixable by neither us nor users) to link properly with functions
declared using C types defined in properly-namespaced headers. The
problem this solves is that C headers (which C++ programmers do persist
in using) frequently forward-declare C struct tags without including
the header where the type is defined, as in
struct tm;
void munge(tm*);
Without some compiler accommodation, munge cannot be called by correct
C++ code using a pointer to a correctly-scoped tm* value.
Nathan Myers
ncm at cantrip dot org