This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/13864] stl_hastable.h Line 527
- From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 26 Jan 2004 14:30:01 -0000
- Subject: [Bug libstdc++/13864] stl_hastable.h Line 527
- References: <20040126054235.13864.greg.bertin@solacesystems.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-01-26 14:29 -------
(In reply to comment #3)
> Subject: RE: stl_hastable.h Line 527
>
> Hi pinskia ...
>
> __n is initialized but the memory being pointed at by __n is not. It is
> memory allocated via _M_get_node():
>
> _Node* _M_get_node() { return _M_node_allocator.allocate(1); }
>
> Allocators return uninitialized memory blocks. This is a problem because
> _Construct():
>
> template <class _T1, class _T2>
> inline void
> _Construct(_T1* __p, const _T2& __value)
> { new (static_cast<void*>(__p)) _T1(__value); }
>
> assumes that __p points to a properly initialized T1 object since it
> invokes T1's copy constructor. T1's copy constructor will assume that
> T1's members (e.g. pointer members that are not NULL and thus need to be
> deallocate()'d/delete()'d/free()'d/whatever) have been properly
> initialized.
No, the copy constructor does not assume anything for the new object.
And also this is using inplacement operator new which just uses the memory location
that you are taking and makes a new object out of that location. In this case it points to
&__n->_M_val (notice the & which means take the address and not something __n->_M_val points
to so that address is always valid as long as __n is which in this case is true).
You need to go read a book about C++ and C for more information about this, this is still valid and
correct C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13864