Fix open_memstream namespace (bug 18498)

open_memstream is new in the 2008 edition of POSIX.  However, the
older functions getopt, closelog and fmtmsg all bring in references to
it.  This patch fixes this in the usual way, making open_memstream
into a weak alias of __open_memstream and calling __open_memstream
from the relevant places.

Tested for x86_64 and x86 (testsuite, and that disassembly of
installed shared libraries is unchanged by the patch).  32-bit builds
produce a XPASS for conform/POSIX/unistd.h/linknamespace after this
patch (because the only cause of failure left there now is 64-bit
specific); that will disappear once the 64-bit failure is resolved and
the XFAIL removed at that time.

2015-06-05  Joseph Myers  <joseph@codesourcery.com>

	[BZ #18498]
	* libio/memstream.c (open_memstream): Rename to __open_memstream
	and define as weak alias of __open_memstream.
	* include/stdio.h (__open_memstream): Declare.  Use
	libc_hidden_proto.
	(open_memstream): Don't use libc_hidden_proto.
	* misc/syslog.c (__vsyslog_chk): Call __open_memstream instead of
	open_memstream.
	* posix/getopt.c (_getopt_internal_r): Likewise.
	* conform/Makefile (test-xfail-XPG3/stdio.h/linknamespace): Remove
	variable.
	(test-xfail-XPG4/stdio.h/linknamespace): Likewise.
	(test-xfail-UNIX98/stdio.h/linknamespace): Likewise.
	(test-xfail-XOPEN2K/unistd.h/linknamespace): Likewise.

> +/* The prototype needs repeating instead of using __typeof to use
> +   __THROW in C++.  */
> +extern FILE *__open_memstream (char **, size_t *) __THROW __wur;
> +libc_hidden_proto (__open_memstream)

Does "extern __typeof (open_memstream) __open_memstream __THROW __wur;" not
work?  That would be less duplication anyway.  Regardless, the comment
reads as odd in its mention of C++ since there is C++ code in libc to be
calling this.

Substantively the change looks fine to me.

On Fri, 5 Jun 2015, Roland McGrath wrote:

> > +/* The prototype needs repeating instead of using __typeof to use
> > +   __THROW in C++.  */
> > +extern FILE *__open_memstream (char **, size_t *) __THROW __wur;
> > +libc_hidden_proto (__open_memstream)
> 
> Does "extern __typeof (open_memstream) __open_memstream __THROW __wur;" not
> work?  That would be less duplication anyway.  Regardless, the comment
> reads as odd in its mention of C++ since there is C++ code in libc to be
> calling this.

The C++ code is in testcases, which produce an "expected initializer 
before 'throw'" error if you use the typeof construct (that is, C++ throw 
() only works with an actual function declarator, not when typeof is used 
to give something a function type).  Hence the comment, to explain why 
__typeof isn't used.

> The C++ code is in testcases, which produce an "expected initializer 
> before 'throw'" error if you use the typeof construct (that is, C++ throw 
> () only works with an actual function declarator, not when typeof is used 
> to give something a function type).  Hence the comment, to explain why 
> __typeof isn't used.

OK.  It would not have looked so odd to me if the comment said "C++ tests".
Perhaps also some sort of XXX/TODO comment about how this should go away
when we one day stop building tests with the internal headers.


Thanks,
Roland

> > The C++ code is in testcases, which produce an "expected initializer 
> > before 'throw'" error if you use the typeof construct (that is, C++ throw 
> > () only works with an actual function declarator, not when typeof is used 
> > to give something a function type).  Hence the comment, to explain why 
> > __typeof isn't used.
> 
> OK.  It would not have looked so odd to me if the comment said "C++ tests".
> Perhaps also some sort of XXX/TODO comment about how this should go away
> when we one day stop building tests with the internal headers.

Or the decl could just use typeof and be under #ifdef _LIBC, no?

On Sat, 6 Jun 2015, Roland McGrath wrote:

> > > The C++ code is in testcases, which produce an "expected initializer 
> > > before 'throw'" error if you use the typeof construct (that is, C++ throw 
> > > () only works with an actual function declarator, not when typeof is used 
> > > to give something a function type).  Hence the comment, to explain why 
> > > __typeof isn't used.
> > 
> > OK.  It would not have looked so odd to me if the comment said "C++ tests".
> > Perhaps also some sort of XXX/TODO comment about how this should go away
> > when we one day stop building tests with the internal headers.
> 
> Or the decl could just use typeof and be under #ifdef _LIBC, no?

I've made the comment say "C++ tests".  This matches what we do in 
wchar.h.  As far as I know we still define _LIBC when building tests, as 
well as using internal headers for them.