[Feature] pragma bitfield_limit

[smiRaphi]

What feature would you like to see?

A pragma to increase the limit of the bitfield beyond 255.

How will this feature be useful to you and others?

The ability to read bigger numbers in bitfields.

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

[paxcut]

Why do you think bitfields are limited to 255 values. an unsigned byte goes from 0 to 255, but bitfields can have more than 8 bits.

[smiRaphi]

No I meant that a single value in a bitfield is currently limited to 255, this for example will just end up as a length of 0:

bitfield test {
    signed value : 256;
};

[paxcut]

Having a pragma to increase the number of bits in a bitfield is not what's needed here. You have to be able to support numbers that are that big because compilers have at most 128 bit integers. I suspect that ImHex is emulating integers of 255 bits but thats probably the limit of the emulation. bigger numbers would probably require an implementation of one of the big number libraries that are arounf. the biggest number imhex seems to be able to create is 170141183460469231731687303715884105727. Do you need bigger numbers than that?

[smiRaphi]

Yes, I need to read a signed number that (theoretically) can go up to a length of 128 bytes (not bits).

[paxcut]

You can't define numbers that are bigger than 128 bit using imhex. Even if the bitfield allows to enter numbers bigger than 128 the actual number stored is still 128 bits at most. For example if you create a bitfield with 129 bit entry and assign to it the value of all bits turned to one the resulting number is just 1. The number I wrote above is 2^127.

[smiRaphi]

That's why this issue exists, I don't actually want to store a number that needs 1024 bits, just read a number that is stored in 1024 bits, even when it only needs like 16

[paxcut]

I don't understand the feature request asking for a pragma to increase the number of bits that an integer can have. Are you asking for imhex to support 1024 bit numbers? Probably not, so then what you probably need is to create a bitfield that has 1024 bits inside of it, but not in a single variable. Something like this:

bitfield Byte {
  byte : 8;
};

bitfield U1024 {
  Byte u1024[128];
};
U1024 bigNumber @0;

[smiRaphi]

But that won't display as a single number and also isn't signed. And I'm not asking for a pragma that increases the overall integer size but just the size that can be read with a bitfield.

[paxcut]

Currently this is the limit of the size that can be used in ImHex:

bitfield BF {
  bf : 128;
};

the limit is imposed by the biggest possible integer size that ImHex can use as variables in pattern language. Increasing that number requires increasing the size of the integer so you are in fact asking to support numbers bigger than 128 bits.
How could you deal with something like this?

bitfield BIG {
  bf : 1024;
};
BIG b1,b2,b3;
b1.bf = std::math::pow(2,512);
b2.bf = std::math::pow(2,130);
b3.bf = b1.bf+b2.bf;

[smiRaphi]

1. You're wrong, the limit is 255
2. You don't, I only want to read a number that theoretically could use 1024 bits but in practice never needs more than like 16 but still is 1024 bits long just padded with a bunch of zeros (or when signed and it's set to -1 it's all FF)

[paxcut]

1. I am not wrong. If you use a number bigger than 128 the lower 128 bits are ignored and only the remaining bits are displayed in the value. Did you actually test it and was able to create a number bigger than 2^127?

2. then use the following. if you only need 16 bytes and want to pad to 1024 bits that you can currently do. The values of the padding even when it is -1 are not important because they are not used in calculations.

bitfield S1024 {
    signed value : 16;
   u8 padding[130];
};

[smiRaphi]

yeah but they could be, also if ImHex just ignores the lower 128bits, why not allow it to go to 1024 and then ignore everything past 128bits? Why even allow 255 in the first place?

[paxcut]

I suspect there is a bug that is allowing numbers bigger than 128 to be used as bitfield field size. If you just want to ignore everything after the first 128 or any other size smaller then use padding to create a variable of the size you want like i posted above.

[paxcut]

Consider this input:

If I write:

bitfield Test {
  signed test : 128;
};


Test t@0;

I get a test variable that is 16 bytes long with value 158798437896437949616241483468158498679 which is correct.
If I do this instead:

bitfield Test {
  signed test : 136;
};


Test t@0;

then test is 17 bytes but its value is 119 (0x77) so only the first byte is used for the value and the other 128 are ignored and can be set to any value and the output will not change.