Add length constraints in placement positions

[Mrmaxmeier]

Hi,

many patterns have length fields that describe the "working area" of a sub-pattern. In lots of cases though, this information is lost if we, i.e., then parse a fixed-size field.

For example: The PNG pattern is a TLV format where some tags have a fixed size.
Many of the if-else arms here https://github.com/WerWolv/ImHex-Patterns/blob/083042632dda00fe7bbc13da037cd6e2472e4c7c/patterns/png.hexpat#L145 don't respect or use the length field.

In these cases we could check if the length matches after parsing by testing it manually:

u32 length;
u64 savedPosition = $;
Payload payload;
std::assert_warn($ - savedPosition == length);

I think it'd be cool to have syntax that encodes these semantics and possibly also constraints the input area for reading operations. (The example above doesn't notice if Payload loads from a pointer field but this would probably be unwanted?)

There's a few open questions for a design like this though:

Semantics

The simple fallback implementation above expects the pattern to fix exactly. I think this is the most common case.
Should Struct x @ 0..8 also allow placement of smaller structs, or should it require the placed variable to be exactly 8 bytes long?

I think it would also be useful to constrain the "working area" of the placed pattern in memory by, i.e., checking that each read is contained in the provided range. Does this break user's assumptions? I think this would be the expected behavior in most cases.

Should patterns be allowed to "break out" of the current "working area"? I think it might be useful to allow placed sub-variables to specify an allowed range that is outside of the current one.

Should it be an error or warning to break the provided constraints?

Syntax

I'm not sure what syntax would work the best here.

• Struct x @ 42..42+len seems natural but what about placing patterns at the current cursor position?
• Maybe the existing in keyword could be used for this? i.e. Pat y in $..$+8?
• Struct x [[area($, $+len)]], Struct x @ pos [[area(pos, pos+len)]]?

---

Feel free to ignore this if you think adding a language feature for something like this is excessive 🙂
Thanks!

[WerWolv]

Hey! Thanks a lot for the suggestion. I do think you're making a good point, right now if one of these fields becomes bigger than expected, the pattern will (most likely) just fail somewhere completely unrelated further down the line which makes debugging difficult.

We do have an attribute called [[fixed_size(size)]] that kinda does what you're asking but it isn't well documented or used much currently. When this attribute is attached to a type or a variable, the runtime will force the type to always have that expected size. If the type is smaller than the expected size, it's padded until it reaches that size. If it's larger than the expected size, evaluation fails with the following error: Pattern of type {} is larger than expected. Expected size {}, got {}.

Updating some of the older patterns to use this attribute would certainly be a good idea.

[Mrmaxmeier]

Ah nice, [[fixed_size(size)]] is mostly what I'm looking for. Thanks!