Deallocating memory with only the address of the data

[MaxRock]

I'm "reverse engineering" a game (Neverwinter Nights) as part of a project that hooks into the game process using madCodeHook.dll (www.nwnx.org) to provide functionality not included using the game's own script engine.
Having rebuilt the struct of a game object, it's easy enough to change numerical values. Changing strings, e.g.: the displayed name of a game object, seems to be a whole different matter though: Allocating memory for a new string and moving the pointer to it works fine but leaves a memory leak because the old string isn't deallocated.

Is it at all possible to deallocate the memory of a character sequence if only it's place in memory is known?

[helios]

Can't you just change the array itself?

[1yR4jE8b]

+1 to what Helios said, also:

If you already have the pointer to the original string, why can't you just delete the string before moving the pointer to the new string?

delete oldString;
oldString = &newString;

[Zhuge]

The pointer does not care how long the data is. As long as you have allocated the space it should be fine.

[MaxRock]

Ahh! I wasn't sure simply calling delete on it would work.

I admit that I have no clue what new and delete actually do. Like if there is a "table" that keeps track of what memory is allocated and which one is free to be used.

Edit:
Sorry, my last post was meant in reply to changing the array itself and whether putting a longer string in it would be "bad".

[Zhuge]

That is really the job of the OS. You just have to make sure you delete everything you new, and that you don't delete things that you didn't new.

[MaxRock]

>>That is really the job of the OS. You just have to make sure you delete everything you new, and that you don't delete things that you didn't new.<<

That's just the problem. I didn't "new" the original string.
Edit: Which I guess doesn't really when I think about it.

[helios]

Edit: Which I guess doesn't really when I think about it.

I assume the missing word there is "matter".
It does matter, because if you don't know how the array was allocated, you can't know how to deallocate it.
Suppose the programmers liked to play mind games and allocated the array like this:

array=new T[n];
array=(T *)(((char *)array)+1)

If you just tried to delete[] array, the program would be likely to crash.

That's a contrived example, but it's also a simplification of a more common situation: the program chooses to manage its own memory by allocating chunks of memory and using its own malloc() implementation. Then any attempt at deallocating a pointer will almost certainly fail because the pointer probably points to the middle of an allocated buffer. If the program doesn't crash, its state will be corrupted (imagine what would happen if one of the OS's pages suddenly disappeared without the OS knowing about it), and it will crash sooner or later.

[MaxRock]

Wouldn't that also mean that if I re-allocate the array there is a potential crash (or memory leak) when the mind games playing programmer's own deallocate function tries to free the memory?

I guess the only way to know for sure would be to actually reverse engineer the part where memory allocation takes place.

[helios]

Wouldn't that also mean that if I re-allocate the array there is a potential crash (or memory leak) when the mind games playing programmer's own deallocate function tries to free the memory?

Exactly. But you might be able to solve it if you know when that happens and keep the old pointer around. Then it's just a matter of deleting your pointer and putting back the old one.