[llvm-bugs] [Bug 43300] New: constructing an ios_base::Init object clobbers stream state

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43300

            Bug ID: 43300
           Summary: constructing an ios_base::Init object clobbers stream
                    state
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: richard-llvm at metafoo.co.uk
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

Constructing an object of type std::ios_base::Init is supposed to have no
effect when the IO streams have already been initialized. In libc++, that is
not the case.

Testcase:


#include <iostream>

int main() {
    std::cout << "hello, " << std::boolalpha;
    std::ios_base::Init init_streams;
    std::cout << true << " world!";
}


... should print "hello true world!" but with libc++ prints "hello 1 world!".

This also presumably means that a multithreaded program that constructs an Init
object has a data race. This seems straightforward to fix by adding a static
one-time initialization guard to the iso_base::Init constructor.

It might also be reasonable to maintain an atomic count of the number of extant
Init objects so that the flushes in the destructor are only run when the last
one is destroyed, as [ios.init]/4 requires. I think that the current destructor
behavior might even result in observable nonconformance in programs that call
cout.rdbuf(stream) and observe when stream sees writes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190912/a18e9cbe/attachment.html>