gStringPtr = new char[..];
// copy something into gStringPtr
strcpy(gStringPtr, "...");
// save address
unsigned int addr = (unsigned int)gStringPtr;
char* copy = (char*)addr;
strcpy(copy, "Blabla"); // Crashes
A problem with strcpy
Author
Hi,
in my project i need to store the memory address of strings, to access them later. for some implementation specific reasons, the code enforces that i have to store that address in a variable of an unsigned int type rather than directly in a pointer.
here is an example:
The call to strcpy crashes, although it points to the correct memory address saved before.
Can someone help me with this problem? I have no idea of how to solve my problem.
Thanks
Gammastrahler
- Casting a pointer to unsigned int isn't safe, particularly with 64-bit systems. If you're compiling to 64-bit code that could be cutting off half of your pointer, which would definitely be a problem.
- strcpy() is deprecated and unsafe. It can't check the bounds of the strings it's copying, and if one of them isn't null-terminated or the buffers aren't the proper size things will explode. This is a likely problem. Make sure the buffer you're allocating is large enough to contain the string plus a null terminator. Then dump strcpy() because it shouldn't be used anymore.
- You're using C++ (new), so why are you using C-style strings? This isn't necessarily the problem, but it'll certainly make things easier for you and everyone who has to read your code. Not to mention it would entirely eliminate the problem you're having right now. Use std::strings.
Really, don't use strcopy().
Quote:man strcopy
The strcpy() function is easily misused in a manner which enables mali-
cious users to arbitrarily change a running program's functionality
through a buffer overflow attack. (See the FSA and EXAMPLES.)
The problem is simple and very common. You are confused about what a string is here. A string consists of a block of memory and the address of that block of memory.
When you do something like gStringPtr = new char[4];, you are allocating a block of 4 bytes (which holds 3 characters plus a terminator) and storing the address of that block in a pointer. When you copy the pointer to a string, you are copying the value of the pointer (the address of the string) and nothing more. When you do strcpy(copy, "Blabla");, you copying 7 bytes into that 4-byte block. Obviously, it is too small and the result is usually (but not always) a crash.
I don't completely agree with Ra's arguments, but I do agree that you should use std::string if you can. It will prevent a bunch of problems that you want to avoid encountering until you have a better grasp of what's going on.
When you do something like gStringPtr = new char[4];, you are allocating a block of 4 bytes (which holds 3 characters plus a terminator) and storing the address of that block in a pointer. When you copy the pointer to a string, you are copying the value of the pointer (the address of the string) and nothing more. When you do strcpy(copy, "Blabla");, you copying 7 bytes into that 4-byte block. Obviously, it is too small and the result is usually (but not always) a crash.
I don't completely agree with Ra's arguments, but I do agree that you should use std::string if you can. It will prevent a bunch of problems that you want to avoid encountering until you have a better grasp of what's going on.
Quote:Original post by Gammastrahler
Can someone help me with this problem? I have no idea of how to solve my problem.
You can most effectively help your self by freeing yourself of the "implementation specific reasons", using real C++ instead of whatever that stuff is called, and along with it a real string type, namely std::string.
(Otherwise: is the memory big enough to hold the new value? Does it still belong to you - i.e. could it have previously been delete'd? Can you show that there is no opportunity for stack or heap corruption anywhere else in your program (as all bets are off for the entire program as soon as any such thing happens)?)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
