[v3 PATCH] Implement LWG 2221, No formatted output operator for nullptr

Jonathan Wakely jwakely@redhat.com
Fri Jan 11 00:01:00 GMT 2019

On 10/01/19 22:27 +0100, Rainer Orth wrote:
>Hi Jonathan,
>> On 04/12/17 23:04 +0000, Jonathan Wakely wrote:
>>>On 03/12/17 23:08 +0200, Ville Voutilainen wrote:
>>>>Tested on Linux-x64.
>>>>2017-11-14  Ville Voutilainen  <ville.voutilainen@gmail.com>
>>>>   Implement LWG 2221
>>>>   * include/std/ostream (operator<<(nullptr_t)): New.
>>>>   * testsuite/27_io/basic_ostream/inserters_other/char/lwg2221.cc: New.
>>>>diff --git a/libstdc++-v3/include/std/ostream
>>>> b/libstdc++-v3/include/std/ostream
>>>>index f7cab03..18011bc 100644
>>>>--- a/libstdc++-v3/include/std/ostream
>>>>+++ b/libstdc++-v3/include/std/ostream
>>>>@@ -245,6 +245,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>>      operator<<(const void* __p)
>>>>      { return _M_insert(__p); }
>>>>+#if __cplusplus > 201402L
>>>>+      __ostream_type&
>>>>+      operator<<(nullptr_t)
>>>>+      { return *this << "nullptr"; }
>>>As discussed on IRC, this requires a new symbol to be exported for the
>>>std::ostream and std::wostream explicit instantiations, or the new
>>>test will fail to link at -O0.
>>>That should wait for stage 1.
>> This patch for a C++17 feature (posted over a year ago) should have
>> gone in during stage 1. I've taken care of the symbol exports that
>> were missing from the original patch.
>> Tested x86_64-linux, committed to trunk.
>this patch broke Solaris bootstrap:
>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol 'std::basic_ostream<char, std::char_traits<char> >::operator<<(decltype(nullptr))': symbol version conflict
>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol 'std::basic_ostream<wchar_t, std::char_traits<wchar_t> >::operator<<(decltype(nullptr))': symbol version conflict
>ld: fatal: libstdc++-symbols.ver-sun: 7117: symbol '_ZNSolsEDn': symbol version conflict
>ld: fatal: libstdc++-symbols.ver-sun: 7119: symbol '_ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn': symbol version conflict
>Again, there were two matches for those two symbols:
>  GLIBCXX_3.4
>    ##_ZNSolsE*[^Dg] (glob)
>    _ZNSolsEDn;
>  GLIBCXX_3.4.26
>    ##_ZNSolsEDn (glob)
>    _ZNSolsEDn;
>  GLIBCXX_3.4
>    ##_ZNSt13basic_ostreamIwSt11char_traitsIwEElsE*[^Dg] (glob)
>    _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn;
>  GLIBCXX_3.4.26
>    ##_ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn (glob)
>    _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEDn;
>ISTM that the patterns were backwards.  The following patch fixes this
>and allowed i386-pc-solaris2.11 bootstrap to complete without
>regressions relative to the last successful one.

I think what I should have done is change [^g] to [^gn]. That
preserves the original behaviour (don't match the ppc64 long double
symbols) but also excludes the new symbols, which end in 'n'.

Maybe the attached patch would be better though. It matches every
basic_ostream::operator<<(T) for any scalar T except 'g', and adds a
second pattern to match basic_ostream::operator<<(T*) for various T.
But neither of those matches the new operator<<(nullptr_t) overload.

FWIW I did run my symbol checker script, but it gets lots of false
positives because it doesn't understand the #if preprocessor
conditions, so it sees lots of false positive duplicates. I need to
make it smarter for it to be useful here.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 953 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20190111/891d4ab4/attachment.bin>

More information about the Libstdc++ mailing list