Re: Included Interfaces without documentation update

[Dan Kegel <dank@kegel.com>]

Dan Kegel wrote:
> > > 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.
> > > ...
> > > 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.  
> > ...
> > I don't see directly how it can end in a user program that's linked
> > shared against libstdc++ but it will end in a user program that's
> > linked static against libstdc++ - and that's the way we advise in the
> > LSB to work around the different GCC releases until 3.0 comes out.
> 
> Thanks for the explanation.  It worries me that we're mandating
> a whole bunch of interfaces which are strictly internal to the
> c/c++ standard libraries.  Can these be put into a separate section
> of the ABI definition, that can be deprecated later when 3.0 is
> out, and we can all happily use dynamic linking?

Getting back to the original topic, it looks like the documentation
for the symbols
 _IO_2_1_stderr_
 _IO_2_1_stdin_
 _IO_2_1_stdout_
 _IO_feof
 _IO_getc
 _IO_putc
 _IO_puts      

could be something like this:

  These are internal aliases used in the interface between glibc and
  gnu stdlibc++ for the symbols stderr, stdin, stdout, feof, getc,
  putc, and puts.  Use programs should not directly reference these.  
  These are only used by programs that link statically to gnu libstdc++.
  These may be deprecated in a future version of this standard, once
  the final C++ ABI is deployed.

Andreas, is that accurate?

Are there other symbols that fall in this category?

- Dan