Re: Included Interfaces without documentation update

[Dan Kegel <dank@kegel.com>]

Andreas Jaeger wrote:
> 
> Dan Kegel <dank@kegel.com> writes:
> 
> > Andreas Jaeger wrote:
> > > > > > > > Andreas Jaeger wrote:
> > > > > > > > > > _IO_putc
> > > > > > > > > Mangle for putc
> > > > > > > > > > _IO_puts
> > > > > > > > > Mangle for puts
> > > > > > > >
> > > > > > > > That's interesting.  I had no idea there were versions of feof etc.
> > > > > > > > with C++ linkage in the standard libraries.  What standard specifies that?
> > > > > > >
> > > > > > > No standard - that's the way glibc implements them.  Since LSB is not
> > > > > > > going to change glibc, we have to document these.
> > > > > >
> > > > > > Does it also export them with C linkage, then?
> > > > >
> > > > > Definitly - we describe a C ABI here.
> > > >
> > > > That's what I thought.  Then why are we also describing the mangled
> > > > names?  Seems like a bug to specify C++ mangled names for C library
> > > > functions.
> > >
> > > Stuart has run with appcheck some tests and noticed that some
> > > programs, most probably C++ applications or libs, needed these, for
> > > example:
> > >
> > > $ nm /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so |grep putc
> > >          U _IO_putc@@GLIBC_2.0
> > >
> > > Since LSB supports C++, we have to add those symbols,
> >
> > There's nothing technically saying you can't use C linkage in a C++
> > program; in fact, stdio.h is surrounded by extern "C" { ... }
> > to force this.
> 
> We seem to have a communication problem.  Those mangles are needed by
> C++ but have C linkage, they don't have C++ linkage.

No, mangles *define* C++ linkage.  If it's mangled, it's using C++ linkage.
(I feel strange debating this point with Andreas, who should know better than me!
What am I missing?)

Anyway, it looks like it's *not* a C++ mangle.  Look at this:
http://cvsweb.netbsd.org/bsdweb.cgi/gnusrc/gnu/dist/libio/ioputc.c?rev=1.1.1.2
The _IO_ prefix is glibc's private little namespace convention
for C library calls; they define a weak alias to map the conventional
name into their private namespace convention.

'nm /usr/lib/libc.a | grep puts' shows, among other things,
ioputs.o:
00000000 T _IO_puts
00000000 W puts 
'nm /lib/libc.so.6 | grep puts' shows the same stuff, minus filenames.

As far as I can tell, the prefixed names are internal to glibc.
User programs don't import them.
Here's a test case.   I compiled the following code with gcc 2.96 (the 
"Red Hat 7 suprise" release):
  #include <stdio.h>
  main() { fputs("howdy", stdout); }
Running 'nm a.out | grep puts' shows
           U fputs@@GLIBC_2.0  
so indeed, user programs don't see to reference the internal symbols.

I'm a newbie when it comes to glibc, so perhaps Andreas can
explain what the consequences of not exporting the internal prefix
versions of C library functions (like _IO_puts)
would be.  Since user programs don't reference them, it must
be something subtle, like 'virtualfs won't work'
(see http://www.solucorp.qc.ca/virtualfs/virtualfs-6.html )

Thanks,
Dan