[LLVMbugs] [Bug 16238] Modifying a deque from emplace_back produces incorrect results

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16238

Howard Hinnant <hhinnant at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> ---
This is a most amusing example.  I recommend submitting an LWG issue requesting
clarification in this area.  Directions for doing so are here:

http://cplusplus.github.io/LWG/lwg-active.html#submit_issue

I found it interesting to try out the behavior with other containers:

With vector I get:

Marker is my initial marker
Marker is now my initial marker
There are 2 items in the vector:
my other marker
my initial marker
a.out(54710) malloc: *** error for object 0x7ff282c039d8: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

However if I first:

        foos.reserve(2);

Then I get the same results as with deque:


Marker is my initial marker
Marker is now my other marker
There are 2 items in the vector:
my other marker
>

Using list yields:

Marker is my initial marker
Marker is now my initial marker
There are 2 items in the list:
my other marker
my initial marker

In each case, because of exception safety considerations, the container is not
"altered" until the construction of a foo is complete.  That way, if the foo
constructor throws, the container state is unchanged.  For example
vector.size() is not altered until the foo constructor is complete.  Therefore
when the second construction starts before the first one is complete, it is
still appending to a zero-length vector.

This is not an issue that can be addressed in the implementation of the
containers.  The standard needs to say "don't do that."  Formulating wording
for "don't do that" is going to be an interesting challenge.  If you have any
ideas at all on that, please include them in your issue.

-- 
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/20130606/3388fde4/attachment.html>