[Bug c++/22265] New: Non -native type entry is getting added to an STL Map incorrectly

[Bug c++/22265] New: Non -native type entry is getting added to an STL Map incorrectly

[kpbhat at sta dot samsung dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

The bug that I am reporting was confirmed on g++ versions 3.3.1, 3.2.3 and 
2.95.3 on a Linux platform.

Although my simple sample program is quite self-explanatory, here’s the problem 
in a nutshell:

I am maintaining an STL map between IP addresses.  In the sample code, I am 
maintaining a map between 105.52.20.33, 5000 and 47.32.68.95, 6000.

When I display the entries in the map, the second IP address is overwritten by 
the first one.  So instead of the mapping: 

105.52.20.33, 5000 >>-->> 47.32.68.95, 6000 
I get

105.52.20.33, 5000 >>-->> 105.52.20.33, 6000 

The bug does not manifest when the code is compiled using native Solaris 
compiler version "WorkShop Compilers 5.0 02/04/10 C++ 5.0 Patch 107311-17" 

If you need any further clarification, kindly let me know.

Regards,
Kong Posh

/////////////// Source Code Begin ///////////////////////
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#include <string>
#include <map>
#include <iostream>

using namespace std;


struct addrLessThan:public binary_function<const struct sockaddr_in, const 
struct sockaddr_in, bool> 
{ 
  bool operator()(const struct sockaddr_in addr1, const struct sockaddr_in 
addr2) const 
  { 
    bool retVal = true;

    string addrStr1 = inet_ntoa(addr1.sin_addr);
    string addrStr2 = inet_ntoa(addr2.sin_addr);

    if(addrStr1 > addrStr2)
      retVal = false;
    else if(addrStr1 == addrStr2)
      retVal = (addr1.sin_port < addr2.sin_port);

    return retVal;
  } 
}; 



typedef map<struct sockaddr_in, struct sockaddr_in, addrLessThan> IpV4AddrMap;



main()
{
  struct sockaddr_in actualAddress, mappedAddress;

  actualAddress.sin_port=5000;
  actualAddress.sin_addr.s_addr = inet_addr("105.52.20.33");

  mappedAddress.sin_port=6000;
  mappedAddress.sin_addr.s_addr = inet_addr("47.32.68.95");

  IpV4AddrMap map;

  map[actualAddress] = mappedAddress;

  IpV4AddrMap::iterator itor = map.find(actualAddress);

  if(itor != map.end())
  {
    cout << "Key: " << inet_ntoa(itor->first.sin_addr)
         << ", " << itor->first.sin_port << endl
         << "Value: " << inet_ntoa(itor->second.sin_addr)
         << ", " << itor->second.sin_port << endl
         << endl;
  }
  return 0;
}

-- 
           Summary: Non -native type entry is getting added to an STL Map
                    incorrectly
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kpbhat at sta dot samsung dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265

[Bug libstdc++/22265] Non -native type entry is getting added to an STL Map incorrectly

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |libstdc++


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265

[Bug libstdc++/22265] Non -native type entry is getting added to an STL Map incorrectly

[chris at bubblescope dot net]

------- Additional Comments From chris at bubblescope dot net  2005-07-01 09:12 -------
on 4.0.0, ppc-darwin I don't see this problem.

On x86-cygwin 3.4.4 I do, but I don't think it has anything to do with map, or
net, or anything.

Consider the following program below. It prints:

bat:bat

on x86-cygwin 3.4.4

and

bat:zat

on ppc-darwin current CVS

inet_ntoa returns a char* to a fixed internal buffer which contains the decoded
net string. You are calling this function twice in one statement, and if you
print the pointers you are returned you'll find (or at least I find, and I can't
see how it could be otherwise) that these pointers are identical.

Now another question, which I'm not 100% certain at the moment and am happy to
have input on, is what about output this program should give, or if it is undefined.

#include <iostream>
char foo[10]="cat";
char* writestring()
{
 foo[0]='b';
 return foo;
}

char* write2()
{
 foo[0]='z';
 return foo;
}


int main(void)
{ std::cout << writestring() << ":" << write2() << std::endl; } 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265

[Bug libstdc++/22265] Non -native type entry is getting added to an STL Map incorrectly

[chris at bubblescope dot net]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265

[Bug libstdc++/22265] Non -native type entry is getting added to an STL Map incorrectly

[chris at bubblescope dot net]

------- Additional Comments From chris at bubblescope dot net  2005-07-01 09:47 -------
After a little thought (sorry, should have done it before), this bug all comes down to the order of 
execution of function parameters, which I believe is undefined?

BTW, in case I wasn't clear enough in mail before, my belief now is that this is not a bug. There are two 
fixes I can think of.

1) Only call inet_ntoa once per statement.
2) Wrap the return of inet_ntoa in string(), so the first thing you do when you get back the char* pointer 
is copy the string it points to into a std::string. For example, your program works if I replace the nearly 
last line with:

cout << "Key: " << string(inet_ntoa(itor->first.sin_addr))
         << ", " << itor->first.sin_port << endl
         << "Value: " << string(inet_ntoa(itor->second.sin_addr))
         << ", " << itor->second.sin_port << endl
         << endl;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265

[Bug libstdc++/22265] Non -native type entry is getting added to an STL Map incorrectly

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-07-01 11:17 -------
Yes, this is not a bug. For further information, grep for "sequence point" in
the standard, in particular under section 1.9.

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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22265