Re: Included Interfaces without documentation update
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
Reply to: