This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/16612] empty basic_strings can't live in shared memory
- From: "bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 21 Jul 2004 14:02:10 -0000
- Subject: [Bug libstdc++/16612] empty basic_strings can't live in shared memory
- References: <20040718033747.16612.steve.horn@gs.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From bangerth at dealii dot org 2004-07-21 14:02 -------
Not knowing much about the code in question, but here is where I see
the problem: in basic_string.h, we have a representation of the empty
string:
struct _Rep : _Rep_base
{
/*...*/
// The following storage is init'd to 0 by the linker, resulting
// (carefully) in an empty string with one reference.
static size_type _S_empty_rep_storage[];
This member variable is indeed zero initialized in the linker, see
basic_string.tcc:
// Linker sets _S_empty_rep_storage to all 0s (one reference, empty string)
// at static init time (before static ctors are run).
template<typename _CharT, typename _Traits, typename _Alloc>
typename basic_string<_CharT, _Traits, _Alloc>::size_type
basic_string<_CharT, _Traits, _Alloc>::_Rep::_S_empty_rep_storage[
(sizeof(_Rep_base) + sizeof(_CharT) + sizeof(size_type) - 1) /
sizeof(size_type)];
Note that allocation of this memory is done by the linker in the address
space of each program that uses strings, not by an allocator class. Thus,
if two programs use shared memory to communicate with each other, their
_S_empty_rep_storage objects may lie at different addresses. Whether that
is a problem I don't know, but it seems unsafe indeed.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612