Comments and Data Types change offsets when using arrays and class types
jocopa3 opened this issue · 6 comments
If I insert an array or class type into an existing structure then insert/add bytes to the array or class, the offsets for comments and data types following the class/array change.
Example:
In the image below, I have an existing structure and notice that before it is a string class/struct included in the structure. The offset for Pointer 1 and it's comment is currently 0x220:
Next I change the data type of the 32 bytes before Pointer 1 to a class, then add or insert 32 bytes to the class structure:
Notice how the comments and data types now correspond to a different offset, and Pointer 1's comment now corresponds to offset 0x238 instead of 0x220.
That behavior is correct. A class instance directly effects the memory location of the following members. By adding 32 bytes to the class you move pointer 1 and the following members/comments down that far in memory
And I only see you adding 16 bytes to the class size (2 int64's are 16 bytes in size). My previous comment still applies.
Is there any way to avoid it shifting everything following the array or class structure? Also, it's a 16 byte char/ptr union and the two int64's, so 32 bytes total in the class instance. Though technically it's only adding 24 bytes since the initial class size is 8 bytes.
No there is not. In C/C++ the compiler will layout the memory the same way (shift members down to make room for class instance). Since reclass is designed to emulate how real classes are laid out it would be counterintuitive imho to provide a feature like that.
But isn't ReClass meant to help reverse engineer/decompile class structures and the like, meaning users would be reversing what the C/C++ compiler did? In this case, I'm taking the 32 bytes previously inserted by the C/C++ compiler into a class and marking them as a separate class instance, rather than inserting a completely new class instance into an existing class.
Essentially, the C/C++ compiler already shifted to make room for the class instance when the program was compiled, so why should ReClass shift that data once again after-the-fact?
Edit: Why not change the functionality of either insert or add in this scenario so that one shifts data and the other doesn't?
@jocopa3 This is expected functionality. I like that idea of one insert that shifts and another that doesn't. That may be helpful to some, however I have never had a problem when it shifts as I just delete the shifted bytes after I insert/add. I personally don't have time right now to add such a feature, but it's open source, feel free to add it yourself and make a merge request.