header, directory, shadow status

[Nathan Myers]

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