friend CStringT operator+(const CStringT& str1, const CStringT& st

[Guest]

Q: Is there a good way to overcome this apparent bug without modifying the
mfc code?
___________________________________

Info: Although it is NOT a good idea, I seemed to have perhaps located a
bug in this function with the GetLength call whose results are sent to the
sub-call to Concatenate. So I added the following and it asserts on
particular strings that are used. (I am not sure if this makes any
difference, but I am using class derived from CString that ends up calling
this code... However, that class never does anything remotely like touching
any private CString data without going through the very normal exposed
methods.)

Code as modified in CStringT.h file (line# 2013):
friend CStringT operator+( const CStringT& str1, const CStringT& str2 )
{
CStringT strResult( str1.GetManager() );

int str1_GetLength = str1.GetLength();
int str1_lstrlen = lstrlen(str1);
int str2_GetLength = str2.GetLength();
int str2_lstrlen = lstrlen(str2);
ASSERT ( str1_GetLength == str1_lstrlen );
ASSERT ( str2_GetLength == str2_lstrlen );

Concatenate( strResult, str1, str1.GetLength(), str2, str2.GetLength() );

return( strResult );
}
______________________________
Values are as follows as the debugger is about to eexecute the first ASSERT
statement:

str1 {0x0127a658 "<Message>"} const
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &

str2 {0x0127a4a8 "chris logged off."}const
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &

str1_GetLength 9 int

str1_lstrlen 9 int

str2_GetLength 18 int

str2_lstrlen 17 int

Ignore the assert and the result is:
strResult {0x0127a5a8 "<Message>chris logged off."}
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >

________________________________

Notice that in this instance, the second assert will fail. If I ignore it,
then then next time I enter this function on this string to concatenate more,
the str1 length is wrong and the concantenation writes the added string just
after the null so that the result is incorrect.

___________________________________

str1_GetLength 27 int

str1_lstrlen 26 int

str2_GetLength 2 int

str2_lstrlen 2 int

str1 {0x0127a5a8 "<Message>chris logged off."} const
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &

str2 {0x0127a610 "</"} const
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &

strResult {0x012525b8 "<Message>chris logged off."}
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >
_____________________________

Tony_Morris at Teledyne dot com

 

[doug mansell]

The bug is probably in the construction of str2. Can you show us that code?

 

[Guest]

Thanks Doug!

I am not sure why, but my single post to the "VC.ATL" group has been posted
here too...???

Anyhow, your question is a copy of the answer from that group:

The bug is probably in the construction of str2. Can you show us that code?

Right on the mark! I had a transfer function that was doing a += into a
CString that ended up placing one extra NULL in the string. I would have
never guessed that CString would support additional NULLs in the data but
sure enough, the following has the output of incrementing the length even
though the string passed to lstrlen() returns 0 every time!
_____________________________________

CString str("");
TCHAR ch = '\0';

MessageBox:GetActiveWindow(), "Length: " + CTekString(str.GetLength()) ,
"str.GetLength()", MB_OK);
MessageBox:GetActiveWindow(), "Length: " + CTekString(lstrlen(str)) ,
"str.GetLength()", MB_OK);

str += ch;

MessageBox:GetActiveWindow(), "Length: " + CTekString(str.GetLength()) ,
"str.GetLength()", MB_OK);
MessageBox:GetActiveWindow(), "Length: " + CTekString(lstrlen(str)) ,
"str.GetLength()", MB_OK);

str += ch;

MessageBox:GetActiveWindow(), "Length: " + CTekString(str.GetLength()) ,
"str.GetLength()", MB_OK);
MessageBox:GetActiveWindow(), "Length: " + CTekString(lstrlen(str)) ,
"str.GetLength()", MB_OK);
________________________________________
Output:

0
0
1
0
2
0
___________________________________________________

Thank you profusely for the insight!!!

TonyM

Info: Although it is NOT a good idea, I seemed to have perhaps
located a bug in this function with the GetLength call whose results
are sent to the sub-call to Concatenate. So I added the following
and it asserts on particular strings that are used. (I am not sure
if this makes any difference, but I am using class derived from
CString that ends up calling this code... However, that class never
does anything remotely like touching any private CString data without
going through the very normal exposed methods.)

Code as modified in CStringT.h file (line# 2013):
friend CStringT operator+( const CStringT& str1, const CStringT& str2
) {
CStringT strResult( str1.GetManager() );

int str1_GetLength = str1.GetLength();
int str1_lstrlen = lstrlen(str1);
int str2_GetLength = str2.GetLength();
int str2_lstrlen = lstrlen(str2);
ASSERT ( str1_GetLength == str1_lstrlen );
ASSERT ( str2_GetLength == str2_lstrlen );

Concatenate( strResult, str1, str1.GetLength(), str2,
str2.GetLength() );

return( strResult );
}
______________________________
Values are as follows as the debugger is about to eexecute the first
ASSERT statement:

str1 {0x0127a658 "<Message>"} const
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &

str2 {0x0127a4a8 "chris logged off."}const
ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &

str1_GetLength 9 int

str1_lstrlen 9 int

str2_GetLength 18 int

str2_lstrlen 17 int

CString supports embedded NULs in strings. In the presence of embedded
NULs, GetLength differs from lstrlen. So the question is, how did you
set up str2 so that it ended up with an extra NUL at the end? Show a
complete program, where you set up the arguments and then invoke the
operator.
--
With best wishes,
Igor Tandetnik

"On two occasions, I have been asked [by members of Parliament], 'Pray,
Mr. Babbage, if you put into the machine wrong figures, will the right
answers come out?' I am not able to rightly apprehend the kind of
confusion of ideas that could provoke such a question." -- Charles
Babbage