uClibc++: bug in map::operator[]

[Carmelo AMOROSO]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Hochreutiner wrote:
> Hi there,
> 
> I am facing a problem with the uClibc++ implementation of std::map,
> which can be illustrated with the following code:
> 
uClibc++ is not uCLibc.
Please post your question to the proper list.

Cheers,
Carmelo

> <-----------SNIP----------->
> #include <cstdio>
> #include <map>
> 
> class my_type
> {
> public:
> 	my_type() : id(count++) { printf("my_type() %d\n", id); }
> 
>     void test() { printf("test() %d\n", id); }
> 
> 	int id;
> 	static int count;
> };
> 
> int my_type::count = 0;
> 
> int main()
> {
>     std::map<int, my_type> mymap;
>     mymap[1].test();
>     mymap[1].test();
> }
> <-----------SNIP----------->
> 
> I expect the output of the above code to be:
> my_type() 0
> test() 0
> test() 0
> 
> 
> i.e. a my_type object is constructed during the first call to
> map::operator[]. The second call should just return a reference to the
> object but not construct a new one. The above output is what I get
> with libstdc++ and visual studio 2005. With uClibc++ however, I get:
> 
> my_type() 0
> test() 0
> my_type() 1
> test() 0
> 
> i.e. a second my_type object is constructed during the second call to
> operator[], but the correct instance (the one constructed during the
> first call) is returned. I've had a look to uClibc++'s map::operator[]
> and it looks like this:
> 
> <-----------SNIP----------->
> 	reference operator[](const key_type& k){
> 		//This is from the spec and is quite ugly.
> 		return (*((insert(make_pair(k, T()))).first)).second;
> 	}
> <-----------SNIP----------->
> 
> The problem is, 'T()'  will construct a new object regardless of
> whether the key 'k' exists in the map or not.
> 
> In most situations, this behaviour does not pose any problem. But in
> some cases, it can have side effects (as in the example above).
> 
> I've seen that this implementation of operator[] was introduced in
> commit 9655, but the old code was working as expected, so IMO it
> should be reverted.
> 
> In addition, is this code really in ISO/IEC 14882:1998 as the comment
> suggests ? It is referenced at
> http://www.sgi.com/tech/stl/Map.html
> and
> http://www.cplusplus.com/reference/stl/map/operator%5B%5D.html
> but is this conform to what ISO says ?
> 
> Thanks,
> 
> Olivier Hochreutiner
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAknUa6EACgkQoRq/3BrK1s/7VgCfSFm+ym+1mUcNq95iEhWG3/hS
smEAn38yNaJ8mzBgiD6Ilzp8iE0AkAkb
=SEI1
-----END PGP SIGNATURE-----