[Bug] Incorrect values in pattern data view for arrays of elements smaller than 1 byte.

[paxcut]

Operating System

Windows

What's the issue you encountered?

When an array is made of elements smaller than 1 byte, the size of the array and the start and end of some values are incorrectly displayed in pattern data window.

How can the issue be reproduced?

The following simple pattern

#pragma example 0x14;

bitfield u4 {
    data : 4;
};

u4 test[2] @ 0;

Should create an array of size 1 byte and the two elements should occupy the lowers and the upper 4 bits respectively. Instead the patter data view shows the following:

The size and the end of the array are incorrect and the position of one of the array elements is also wrong.

ImHex Version

1.39.0wip

ImHex Build Type

• Nightly or built from sources

Installation type

built locally

Additional context?

No response

[laurenhall1526-netizen]

Looks like a misalignment issue with sub-byte array elements. The array should indeed pack into a single byte with each u4 taking 4 bits. I can try to reproduce this on my end. Do you know if this also happens with other bit sizes (like u2 or mixed bitfields), or just u4?

…

On Mon, Apr 6, 2026, 10:22 AM paxcut ***@***.***> wrote: *paxcut* created an issue (WerWolv/ImHex#2700) <#2700> Operating System Windows What's the issue you encountered? When an array is made of elements smaller than 1 byte, the size of the array and the start and end of some values are incorrectly displayed in pattern data window. How can the issue be reproduced? The following simple pattern #pragma example 0x14; bitfield u4 { data : 4; }; u4 test[2] @ 0; Should create an array of size 1 byte and the two elements should occupy the lowers and the upper 4 bits respectively. Instead the patter data view shows the following: image.png (view on web) <https://github.com/user-attachments/assets/3fd69e9c-c061-4def-851c-0992531546aa> The size and the end of the array are incorrect and the position of one of the array elements is also wrong. ImHex Version 1.39.0wip ImHex Build Type - Nightly or built from sources Installation type built locally Additional context? *No response* — Reply to this email directly, view it on GitHub <#2700>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7IHA42F47YXGKFFEFMRHWT4UPDSVAVCNFSM6AAAAACXOIAIESVHI2DSMVQWIX3LMV43ASLTON2WKOZUGIYTENBWGMYDKMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[paxcut]

I think the code assumes that every array element must be at least 8 bits. Thus an array of two u4 is thought of being 2 bytes and all the elements are thought to take the first 4 bits. If you create an array of 4 u2's then the size is reported as 4.
Note that if you mark the bitfield as static, then each array member will become 8 bits so maybe the code assumes that the array of bitfields is static when determining its size and location.

[colincaldwell1231-design]

Thanks for the clear report and minimal repro — very helpful.

…

On Mon, Apr 6, 2026, 4:22 PM paxcut ***@***.***> wrote: *paxcut* created an issue (WerWolv/ImHex#2700) <#2700> Operating System Windows What's the issue you encountered? When an array is made of elements smaller than 1 byte, the size of the array and the start and end of some values are incorrectly displayed in pattern data window. How can the issue be reproduced? The following simple pattern #pragma example 0x14; bitfield u4 { data : 4; }; u4 test[2] @ 0; Should create an array of size 1 byte and the two elements should occupy the lowers and the upper 4 bits respectively. Instead the patter data view shows the following: image.png (view on web) <https://github.com/user-attachments/assets/3fd69e9c-c061-4def-851c-0992531546aa> The size and the end of the array are incorrect and the position of one of the array elements is also wrong. ImHex Version 1.39.0wip ImHex Build Type - Nightly or built from sources Installation type built locally Additional context? *No response* — Reply to this email directly, view it on GitHub <#2700>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAXNU3VYGQLNSRLYSBSZ7J34UPDSVAVCNFSM6AAAAACXOIAIESVHI2DSMVQWIX3LMV43ASLTON2WKOZUGIYTENBWGMYDKMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[paxcut]

I have found at least three different pieces of code that contribute to this issue. The size of the array is adding the sizes of each element, but, because their size is sub-byte, they are taken to be 1 byte each. I have made some changes that detect when bit-fields are being used and add the bitsizes instead to calculate the size.

The incorrect start values are created because the array elements are the top most bit-field themselves so the code that calculates the offset for display always returns zero. While the array elements can be fixed easily, it is not clear how to extend that fix to also be applied to the bit-field members.

Furthermore if one add two u4 values to an struct that results in two bytes but the size is incorrectly shown as 1 byte. If instead of two u4's one adds an array of 2 u4's, then the size is 1 byte and it is incorrectly shown as 2 bytes because of the error explained before.

The difference between those two cases is that one could place a u8 between the two u4s which would be forced to be byte aligned making the u4 become 1 byte each. So it is important to decide on the rules that force data to become byte aligned or is allowed to add bits not necessarily byte aligned. Until the strict rules are laid out it will not be possible to fix this issue and it is not clear what the exact rule should be .