467,913 Members | 1,823 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,913 developers. It's quick & easy.

strcat - strange behavior

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
Feb 27 '06 #1
  • viewed: 4626
Share:
16 Replies
Lilith 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.
You know that MFC is off-topic, right? Just checking. I understand that
you're not asking about MFC per se.
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
Outputting a string to a display is not defined in C++, you know that,
right? There is no such thing as "display" in C++.
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.
I think this is covered in the FAQ. See 5.8.
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.


I'll believe you when I see the code.

V
--
Please remove capital As from my address when replying by mail
Feb 27 '06 #2
On Mon, 27 Feb 2006 17:08:53 -0500, Victor Bazarov
<v.********@comAcast.net> wrote:
Lilith 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.
You know that MFC is off-topic, right? Just checking. I understand that
you're not asking about MFC per se.
Even when I'm striving for completeness?
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 Outputting a string to a display is not defined in C++, you know that,
right? There is no such thing as "display" in C++.
Yes, and once again, the purpose was completeness. I wanted it
understood why I was appending the CR\LF combination.
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. I think this is covered in the FAQ. See 5.8. 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.

I'll believe you when I see the code.
strcpy (Buffer, "MAIL FROM: ");
m_From.GetWindowText(Text, 512); // sorry if this is MFC
strcat (Buffer, Text); // up to this point the string is nul
// terminated

// 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
V


--
Lilith
Feb 27 '06 #3

Lilith wrote:
On Mon, 27 Feb 2006 17:08:53 -0500, Victor Bazarov
<v.********@comAcast.net> wrote:
Lilith 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.
You know that MFC is off-topic, right? Just checking. I understand that
you're not asking about MFC per se.


Even when I'm striving for completeness?
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
Outputting a string to a display is not defined in C++, you know that,
right? There is no such thing as "display" in C++.


Yes, and once again, the purpose was completeness. I wanted it
understood why I was appending the CR\LF combination.
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.
I think this is covered in the FAQ. See 5.8.

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.

I'll believe you when I see the code.


strcpy (Buffer, "MAIL FROM: ");
m_From.GetWindowText(Text, 512); // sorry if this is MFC
strcat (Buffer, Text); // up to this point the string is nul
// terminated

// 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


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

Feb 27 '06 #4
On 27 Feb 2006 14:43:18 -0800, ro**********@gmail.com wrote:

Lilith wrote:
On Mon, 27 Feb 2006 17:08:53 -0500, Victor Bazarov
<v.********@comAcast.net> wrote:
>Lilith 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.

>You know that MFC is off-topic, right? Just checking. I understand that
>you're not asking about MFC per se.


Even when I'm striving for completeness?
> > 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

>Outputting a string to a display is not defined in C++, you know that,
>right? There is no such thing as "display" in C++.


Yes, and once again, the purpose was completeness. I wanted it
understood why I was appending the CR\LF combination.
> > 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.

>I think this is covered in the FAQ. See 5.8.

> > 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.

>I'll believe you when I see the code.


strcpy (Buffer, "MAIL FROM: ");
m_From.GetWindowText(Text, 512); // sorry if this is MFC
strcat (Buffer, Text); // up to this point the string is nul
// terminated

// 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


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


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

Lots of room.

--
Lilith
Feb 27 '06 #5
Victor Bazarov wrote:
Outputting a string to a display is not defined in C++, you know that,
right? There is no such thing as "display" in C++.


There doesn't have to be, because that's covered in the C standard.

Section "5.2.2 Character display semantics" in 9899:1999.

:)

Feb 27 '06 #6

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.

Feb 27 '06 #7

<ro**********@gmail.com> schrieb im Newsbeitrag
news:11**********************@i40g2000cwc.googlegr oups.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"?
Feb 27 '06 #8
Lilith wrote:
strcpy (Buffer, "MAIL FROM: ");
m_From.GetWindowText(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?

Moreover, you do know that MFC has a CString class?

Moreover, you do know that the control you are using has a
GetWindowText() overload that will put data into a CString object?

void CWnd::GetWindowText(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?

Idiot!

Feb 27 '06 #9
Kaz Kylheku wrote:
Victor Bazarov wrote:
Outputting a string to a display is not defined in C++, you know that,
right? There is no such thing as "display" in C++.

There doesn't have to be, because that's covered in the C standard.

Section "5.2.2 Character display semantics" in 9899:1999.

:)


How is that relevant? AFAIK, C++ Standard only refers to 9899:1990. :)
Feb 27 '06 #10
In article <08********************************@4ax.com>,
Lilith <li****@dcccd.edu> 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.
Feb 28 '06 #11
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
Feb 28 '06 #12
On 27 Feb 2006 15:17:00 -0800, "Kaz Kylheku" <kk******@gmail.com>
wrote:
Lilith wrote:
strcpy (Buffer, "MAIL FROM: ");
m_From.GetWindowText(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::GetWindowText(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
Feb 28 '06 #13
On Tue, 28 Feb 2006 00:16:48 +0100, "Frank Schmidt" <fs@example.com>
wrote:

<ro**********@gmail.com> schrieb im Newsbeitrag
news:11**********************@i40g2000cwc.googleg roups.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
Feb 28 '06 #14
Lilith wrote:
On Tue, 28 Feb 2006 00:16:48 +0100, "Frank Schmidt" <fs@example.com>
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.

Feb 28 '06 #15
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::GetBuffer(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::ReleaseBuffer().

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).

Feb 28 '06 #16
In article <1141145231.183064.132590
@i40g2000cwc.googlegroups.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.
Mar 1 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Jon | last post: by
44 posts views Thread by Nicolas | last post: by
8 posts views Thread by ctara_shafa | last post: by
9 posts views Thread by cicalese | last post: by
87 posts views Thread by Robert Seacord | last post: by
12 posts views Thread by Eric Kaplan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.