string Trouble

[Kohinoor24]

I was trying the foll: code

const char * Text = "CZARIUC=CHS,IND"; //pjtGetFirst();
int size = strlen(Text);
char *Dest = new char(size);
strcpy(Dest,Text);
char *token1 = strtok(Dest,"=");
if (token1=="CZARIUC")
cout<<token1; //But its not going to this statement at all.

Why? & what should I do to make it go..

Thanks in advance..

[Paul McKenzie]

const char * Text = "CZARIUC=CHS,IND"; 
int size = strlen(Text);
char *Dest = new char(size); // Wrong!  
strcpy(Dest,Text);   // Not enough room to copy information!  memory overwrite!

You allocated "size" bytes, but then you call strcpy(). The problem is that strcpy() will copy over size+1 bytes, which will cause a memory overwrite in your code. The extra byte is the terminating NULL. Fix this problem first, and then worry about the rest of your code.

const char * Text = "CZARIUC=CHS,IND"; 
int size = strlen(Text) + 1;
char *Dest = new char(size); 
strcpy(Dest,Text);

Also, since this is C++, why don't you use std::string? You don't worry about these problems with allocation and deletion:

#include <string>
//...
const char * Text = "CZARIUC=CHS,IND"; 
std::string Dest = Text;

No need for new / delete or strcpy.

Regards,

Paul McKenzie

[Graham]

Unfortunately, there isn't (or, rather, I don't know of) an OO equivalent for strtok() in the C++ standard library, so std::string may not be of much help.

In addition to Paul's comments, the immediate cause of the OPs problem is the line:

if (token1=="CZARIUC")

This is not doing what the OP apparently expects, i.e. comparing the two strings. It's actually comparing the values of the two pointers, and is almost guaranteed to fail.

The test should be:

if (strcmp(token1, "CZARIUC") == 0)

[Philip Nicoletti]

Should it be (with size large enough)

char *Dest = new char[size]; // [] instead of () ???

[ltachna]

try this

const char * Text = "CZARIUC=CHS,IND"; //pjtGetFirst();
int size = strlen(Text) + 1;
char *Dest = new char(size);
strcpy(Dest,Text);
char *token1 = strtok(Dest,"=");
if (!strcmp(token1, "CZARIUC"))
cout<<token1;

[Paul McKenzie]

Originally posted by Philip Nicoletti
Should it be (with size large enough)

char *Dest = new char[size]; // [] instead of () ???

Yes, you're right. It should be [] instead of ().

Given all of these problems, I wonder if delete [] is ever called in the OP's code anywhere (and if so, is it "delete []" or just delete).

Regards,

Paul McKenzie

[AnthonyMai]

You allocated "size" bytes, but then you call strcpy(). The problem is that strcpy() will copy over size+1 bytes, which WILL cause a memory overwrite in your code. The extra byte is the terminating NULL. Fix this problem first, and then worry about the rest of your code.

It is is not WILL, it is COULD. Actually in the specific case of the OP it is WOULD NOT.

I don't like the way the OP allocate only strlen() bytes. But it is only a small possibility that you could overwrite the memory by one byte (a 12.5% possibility) this way.

When memory is allocated, it is seldom allocated to the exact size specified. It will allocate memory suitably aligned and sized for the biggest alignment element, which is normally 8 bytes. So you can expect that the pointer to the start of the memory is 8 bytes aligned, and the size is a multiple of 8 bytes.

In the case of OP, the string length is 15 bytes, so 16 bytes or more will be allocated. Copying 15+1 bytes hence will not cause any problem.

[Paul McKenzie]

Originally posted by AnthonyMai


It is is not WILL, it is COULD. Actually in the specific case of the OP it is WOULD NOT.

I don't like the way the OP allocate only strlen() bytes. But it is only a small possibility that you could overwrite the memory by one byte (a 12.5% possibility) this way.

When memory is allocated, it is seldom allocated to the exact size specified. It will allocate memory suitably aligned and sized for the biggest alignment element, which is normally 8 bytes. So you can expect that the pointer to the start of the memory is 8 bytes aligned, and the size is a multiple of 8 bytes.

In the case of OP, the string length is 15 bytes, so 16 bytes or more will be allocated. Copying 15+1 bytes hence will not cause any problem.

Wow, a word such as "will" makes you write so many paragraphs of really nothing important.

My definition of memory overwrite is different than yours. The guy/woman needs "x+1" bytes, allocates only "x", and writes "x+1" bytes to where he/she allocated. Ever hear of the K.I.S.S. principle?

Regards,

Paul McKenzie

[jflegert]

Anthony,

In the case of OP, the string length is 15 bytes, so 16 bytes or more will be allocated. Copying 15+1 bytes hence will not cause any problem.

AS a master debugger, I'm surprised you would be posting such a response. I tried the original poster's code (but deleted some lines):

const char * Text = "CZARIUC=CHS,IND"; //pjtGetFirst(); 
int size = strlen(Text);
char *Dest = new char(size);
strcpy(Dest,Text);
delete [] Dest;

and the debugger outputs the following messages:
HEAP[mem.exe]: Heap block at 002F27D8 modified at 002F2805 past requested size of 25
Unhandled exception at 0x77fa018c in mem.exe: User breakpoint.

The reason is obvious.

If I was grading your response as homework, I would give it a D-.

Hi Paul,

I've never heard of the K.I.S.S principle. What is it?

Thanks and Regards,
John Flegert

[Paul McKenzie]

Hello John,

K.I.S.S.

Keep It Simple, Stupid. It's one of those acronyms that is used the computer industry (and probably others).

Regards,

Paul McKenzie

[AnthonyMai]

and the debugger outputs the following messages:
HEAP[mem.exe]: Heap block at 002F27D8 modified at 002F2805 past requested size of 25
Unhandled exception at 0x77fa018c in mem.exe: User breakpoint.

That's just a debug output, in release build you won't see any thing, in debug build you can adjust the debug flag to tell the debugger what to check and what to ignore, you can choose to ignore the debug exception, or, you can simply link with the none-debug version of the runtime library. In any case it is not a crash, there is no need to make a big deal out of the debug output you see.

The debugger version puts some 0xFD bytes right after the allocated size, to check if you are attempting to access beyond what you asked for. It may or may not actually do the checking. And the release version of CRT library does not do such checking. In any case, the actual allocate space is a few bytes more than you asked for.

In principle, you should not step beyond what you initially asked for when allocating.

In reality, sometimes stepping just one byte beyond the allocated size will NOT cause crash, since the allocated size is always a multiple of 8 or 16.

In practice, allocating just the right size you want is BAD, whether it is size or size+1. You should NEVER allocate something like 4 bytes or 17 bytes using malloc(). You just throw in a lump sum of 512 bytes or 1024 bytes at least, when you probably needed just a few bytes. And it is prefered you try to get the memory on the stack, instead of on the heap.

malloc() is an expensive operation. I always avoid malloc() (implicit or explicit) where ever possible. And if it is unaviodable, give it a big enough chunk. It's pointless doing malloc(17).

[jflegert]

Anthony,

Given your last post, I have lost what little respect I had for your development skills. You are dangerous.

Reagrds,
John Flegert