ImHex
ImHex copied to clipboard
WerWolv
[Feature] structure union bitfield size restriction
What feature would you like to see?
Add attributes "minsize","maxsize","size" to types like:
struct test {
}[[minsize=5,maxsize=10]];/*restrict 5<=sizeof(test)<=10 */
struct test1 {
u8 a; }[[size=8]]; /*restrict sizeof(test)==8 */
How will this feature be useful to you and others?
-
for minsize<maxsize, when sizeof(test)<minsize or sizeof(test)>maxsize, output message to console inluding type, address。
-
when minsize==maxsize, if sizeof(test1)>size will output warning message, else automatically padding bytes at the end of test1, like: struct test1 { u8 a; u8 padding[7]; /* automatically generated field ,can also initially hide */ }[[size=8]]; /*restrict sizeof(test)==8 */
-
attributes can be accssed use: this.minsize, this.maxsize, this.size, this.end, this.end==adrressof(this)+this.size.
Request Type
- [ ] I can provide a PoC for this feature or am willing to work on it myself and submit a PR
Additional context?
No response
I dont really understand the padding part. if a struct contains a dynamic array then it will grow as needed. How can a structure grow beyond its ability to hold data? I think this feature will be useful to restrict the size of some structs from getting bigger than some problem defined size so for example if it is reading characters into a string once it reaches a page size it stops reading and lets a new page start.
padding part is for a struct don't have all the fields defined. Imaging a file only one struct type array: struct A {}[[ size="getSize" ]]；
fn getSize(A a) { return ... }
A a[while(while(!std::mem::eof())];
If stuct size calculated properly , use padding bytes will make every stuct a at proper start address. If padding bytes not used, maybe can set $=addressof(a)+a.size after struct a creation.
For what practical purpose is the struct grown beyond its limits? It seems like if it needs to be bigger then it was not defined properly and needs to be corrected. There are times when you dont know the size of the data that needs to be acquired, but in that case you use structs that can grow to the size and adapt their size dynamically . That already exists and it doesnt need padding.
So either you know the size you want to read or you don't. If you don't then you use dynamic allocation. If you do then statically allocate enough. If you made a mistake then correct it. What other case is there?
It seems to me that size restriction syntax applied to structs should be used to restrict the size of structures at runtime. Allowing them to grow beyond the desired constrains using padding seems counter intuitive. Maybe you are thinking about a different concept other that size restriction, like maybe alignment restrictions or data location constrains.
I would need the same thing.
There is a file that has an array of structs, and the structs each have a fixed size of 0x40 bytes, however their contents are dynamic and contain char[]s (they just can't grow beyond 0x40).
I don't know how I would tell ImHex that there should be a padding that has a variable size to aritificially inflate the struct always to 0x40 bytes. This suggested [size=0x40] attribute sounds exactly like what I need.
isn't sizeof(this) enough to calculate how much padding would you need to reach any size? like
if(sizeof(this) < 0x40)
padding[0x40-sizeof(this)];
Oh. Right. 🤦 I was trying to ask the docs AI but it told me this is not possible.
do you mean this?
The AI seems to have trouble with actions related to the concept of size. for example If you ask how to calculate the size of a variable it tells you there is no way, but if you ask how to obtain the size of a variable it'll say to use sizeof. so asking how to restrict size may be too hard for the doc ai.