strcat - strange behavior

[Lilith]

I'm working on a simple piece of code under VC++ 6.0. I've got a char
Buffer array into which I copy the contents of an MFC control. The
string is properly nul terminated. I use strcat (Buffer, "\r\n") to
append a carriage return\line feed to the string before outputting it
to a display where I can monitor what's being exchanged with another
service. But after the strcat the string in Buffer is terminated, not
with \r\n but with a \n and NO nul terminator. The carriage return is
dropped completely.

If this was output for a text file I'd think it was an expected
conversion. But all of this is still in memory.

TIA,
Lilith

[Daniel T.]

In article <08************ *************** *****@4ax.com>,
Lilith <li****@dcccd.e du> wrote:

I'm working on a simple piece of code under VC++ 6.0. I've got a char
Buffer array into which I copy the contents of an MFC control. The
string is properly nul terminated. I use strcat (Buffer, "\r\n") to
append a carriage return\line feed to the string before outputting it
to a display where I can monitor what's being exchanged with another
service. But after the strcat the string in Buffer is terminated, not
with \r\n but with a \n and NO nul terminator. The carriage return is
dropped completely.

If this was output for a text file I'd think it was an expected
conversion. But all of this is still in memory.

TIA,
Lilith

Lilith, try this:

int main()
{
char buffer[10] = "hello";
strcat( buffer, "\r\n" );
assert( buffer[5] == '\r' );
assert( buffer[6] == '\n' );
assert( buffer[7] == 0 );
cout << "working";
}

If "working" doesn't print out, then I'd say your strcat function is
broken.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Victor Bazarov]

Daniel T. wrote:

[..]
Lilith, try this:
... after adding this:

#include <iostream>
#include <cstring>
#inlcude <cassert>
using namespace std;

(it can be enough to add <iostream> only, but to be complete, use
all headers necessary).

int main()
{
char buffer[10] = "hello";
strcat( buffer, "\r\n" );
assert( buffer[5] == '\r' );
assert( buffer[6] == '\n' );
assert( buffer[7] == 0 );
cout << "working";
}

If "working" doesn't print out, then I'd say your strcat function is
broken.

V
--
Please remove capital As from my address when replying by mail

[Lilith]

On 27 Feb 2006 15:17:00 -0800, "Kaz Kylheku" <kk******@gmail .com>
wrote:

Lilith wrote:

strcpy (Buffer, "MAIL FROM: ");
m_From.GetWindo wText(Text, 512); // sorry if this is MFC
strcat (Buffer, Text); // up to this point the string is nul
// terminated
Neither strcpy() nor strcat() have any mechanism to guard against
storing more characters than the destination array can hold.

// Buffer is passed to a function but is still null
// terminated following the call

strcat(Buffer, "\r\n"); // after this operation the
// string is LF terminated with no
// nul

How do you know? Are you by chance relying on the variable inspection
window of your debugger? That Microsoft thing has certain issues when
it comes to displaying strings. It cuts off strings that are too long,
and I think it basically just stuffs the text into its own control, so
that \r\n just becomes a line break. I haven't used it in a long time,
so I can't quite remember. If you want to be sure what's in that
character array, you should convert it yourself to printable form and
dump it to a debug trace function.

Oh, you do know that C++ has a string class, right?
Yes.
Moreover, you do know that MFC has a CString class?
Yes.
Moreover, you do know that the control you are using has a
GetWindowText( ) overload that will put data into a CString object?
Yes. And under other circumstances I've used it extensively for
getting and setting the text of controls.
void CWnd::GetWindow Text(CString& rString) const; Why are you messing around with strcat instead of using the string type
provided by the framework in which you are making the GUI?
Because the function to which I pass the string specifies a char
array. And, yes, I know that CString resolves to a character pointer
to the character array. It's not my function but I know that the
function ends up outputting the string with more than what I feed it.
So I don't trust it not to manipulate the string before using it. So
I'm playing it safe.
Idiot!

And that's why I don't learn a damn thing. Too many people willing to
exercise their expertise muscles for slamming people rather than
actually trying to help. It's why I hesitate to ask anything in these
forums. It's why I put more detail than some people seem to think I
should so I don't get someone who calls me an "idiot" for not being
explicit enough. Instead I get chidded for mentioning M*C in my post.

Thanks to everyone who tried to help. I'm out of here.

Idiot!

--
Lilith

[Lilith]

On Tue, 28 Feb 2006 00:16:48 +0100, "Frank Schmidt" <[e-mail] >
wrote:

<ro**********@ gmail.com> schrieb im Newsbeitrag
news:11******* *************** @i40g2000cwc.go oglegroups.com. ..

Lilith wrote:

>What is strlen(Buffer) vs. sizeof(Buffer)?

sizeof(Buffer) = 512
strlen(Buffer) := 50

Lots of room.

Skirt the issue then, set buffer to all 0 before processing. Then if
it fails something is modifying it in a way you are not expecting and
you can look for it.

does a strlen of 50 not kinda indicates the real length and that there is a
0 and a wrong "DISPLAY"?

No. All my inspection is done in debug mode. I'm looking at the
string's individual chars and the indexes for the array.

--
Lilith

[Kaz Kylheku]

Lilith wrote:

On Tue, 28 Feb 2006 00:16:48 +0100, "Frank Schmidt" <[e-mail] >
wrote:

does a strlen of 50 not kinda indicates the real length and that there is a
0 and a wrong "DISPLAY"?

No. All my inspection is done in debug mode. I'm looking at the
string's individual chars and the indexes for the array.

Just as I suspected. That's why in my other message I asked: how do you
know? Are you just inspecting via the debugger?

The Visual C++ debugger truncates strings. If you have some "char *p"
object and you want to see more of it, you can type in an expression
like "p + 20".

The IDE does have a memory inspector which you can use instead for
larger objects.

Like I said, idiot.

[Kaz Kylheku]

Lilith wrote:

On 27 Feb 2006 15:17:00 -0800, "Kaz Kylheku" <kk******@gmail .com>
wrote:

Why are you messing around with strcat instead of using the string type
provided by the framework in which you are making the GUI?

Because the function to which I pass the string specifies a char
array. And, yes, I know that CString resolves to a character pointer
to the character array. It's not my function but I know that the
function ends up outputting the string with more than what I feed it.
So I don't trust it not to manipulate the string before using it. So
I'm playing it safe.

Microsoft's CString class supports direct manipulation of the string
data.

It a function by means of which you can pull out a modifiable buffer.
It's different from the char * operator that pulls out a const string
implicitly:

CString::GetBuf fer(int);

The parameter lets you specify how big the buffer should be. It seems
to be designed for the kind of hack where someone wants to add a bit of
data at the end. When you are done fiddling with the buffer, you call

CString::Releas eBuffer().

if you need to do more things with the CString data using its own
methods before you destroy it.

RTFMSDN.

In your case, you can pass in a parameter of 512.

(That's Big Enough (TM) for any function that is suspected of adding
data beyond the end of the string, right? Haha).

[Jerry Coffin]

In article <1141145231.183 064.132590
@i40g2000cwc.go oglegroups.com> , kk******@gmail. com
says...

[ ... ]

In your case, you can pass in a parameter of 512.

(That's Big Enough (TM) for any function that is suspected of adding
data beyond the end of the string, right? Haha).

It works fine on my DeathStation 9000! :-)

--
Later,
Jerry.

The universe is a figment of its own imagination.