std::string memory overwritten?

Question

With this code:

std::string create_bc( std::string   current_bk,
                       std::string   local_isin,
                       std::string   local_fininfo,
                       std::string   local_ccy,
                       std::string   local_ric,
                       QSqlDatabase* db)
{
    std::string req;
    req.reserve(1024);

    req = "dbo.create_bsk_constituent @bk_cod=";
    std::cout << req << std::endl;
    req += current_bk;
    std::cout << req << std::endl;
    req += " , @ISIN= ";
    std::cout << req << std::endl;
    req += local_isin;
    std::cout << req << std::endl;
    req += " , @FININFO= ";
    std::cout << req << std::endl;
    req += local_fininfo;
    std::cout << req << std::endl;
    req += " , @dev_cod= ";
    std::cout << req << std::endl;
    req += local_ccy;
    std::cout << req << std::endl;

I got this output:

dbo.create_bsk_constituent @bk_cod=
dbo.create_bsk_constituent @bk_cod=bk11
dbo.create_bsk_constituent @bk_cod=bk11 , @ISIN=
dbo.create_bsk_constituent @bk_cod=bk11 , @ISIN= EU0009658145
dbo.create_bsk_constituent @bk_cod=bk11 , @ISIN= EU0009658145 , @FININFO=
dbo.create_bsk_constituent @bk_cod=bk11 , @ISIN= EU0009658145 , @FININFO= 22
 , @dev_cod= k_constituent @bk_cod=bk11 , @ISIN= EU0009658145 , @FININFO= 22
 , @dev_cod= EURonstituent @bk_cod=bk11 , @ISIN= EU0009658145 , @FININFO= 22

There seems to be some memory overwriten when "+=" has dev_cod as right operand. For some reason the right operand of += is written at the beginning of the string...

I also wondered about cout, so i tried to add some std::flush everywhere. But it did not make things better.

EDIT

Just so nobody asks. there is only one thread... :)

@Angew thanks ==> applyed dos2unix, and problem was solved. CLOSE

local_fininfo is the en of line of a windows csv file. then local fininfo end up with 0D0A in my hexadecimal editor.

So there was indeed a carriage return that I could not see by printing local fininfo out alone.

Answer 1

It seems there's a carriage-return character in one of the strings, which gets interpreted during output. Perhaps a Windows-style file is being parsed as a Unix-style one somewhere.

Answer 2

There's a carriage return in local_fininfo.