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
16  5072 
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
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
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 displayOutputting 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)?
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
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.
:)
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.
<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"?
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!
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. :)
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.
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
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
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
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.
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).
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jon |
last post by:
using Borland Compiler.
x = "this is a string"
strcat(x,x)
strcat(x,x)
will produce "this is a stringthis is a stringthis is a stringthis is
a stringt"
|
by: Nicolas |
last post by:
On most implementations of the standard C library, the functions that
copy characters in a previously allocated buffer, like strcpy or strcat,
are returning the pointer to that buffer.
On my...
|
by: Matt |
last post by:
I have 2 questions:
1. strlen returns an unsigned (size_t) quantity. Why is an unsigned
value more approprate than a signed value? Why is unsighned value less
appropriate?
2. Would there...
|
by: ctara_shafa |
last post by:
Hi,
I have a following problem: I'm creating a list and one of the fields
should contain the date. Firstly I ask the user for the year, month and
day and then I'd like to collect all this data in...
|
by: cicalese |
last post by:
For starters, I am a C novice. I don't fully understand how strings
work. I am running on a linux box. I compile w/ gcc. I have a string
called 'myabqcommand' that is being overwritten when i use...
|
by: Robert Seacord |
last post by:
The SEI has published CMU/SEI-2006-TR-006 "Specifications for Managed
Strings" and released a "proof-of-concept" implementation of the managed
string library.
The specification, source code for...
|
by: Eric Kaplan |
last post by:
why the following code will crash?
int main()
{
char* str = "aa";
strcat (str, "hello");
cout << str << "\n";
strcat (str, "you1");
cout << str << "\n";
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
| |
