Clicking on boolean fields does not seek in the hex editor

[durka]

I'm seeing multiple issues with display and parsing of boolean (b1) fields.

1. The value is always shown as false, even if the value is 1 (see g below)
2. A b1 right after another b1 does not seem to get assigned to a byte. It gets assigned the same value as the previous field, and clicking on it in the object tree doesn't change the selected byte in the hex viewer. (see b below)

Using an enum with 0: false, 1: true is a workaround.

Included code, data and output below:

meta:
  id: bool
  
enums:
  bool:
    0: false
    1: true

seq:
  - id: a
    type: b1
  - id: b
    type: b1
    
  - id: c        # note: this ends up as the second byte
    type: u1
  - id: d
    type: u1
    
  - id: e
    type: u1
    enum: bool
  - id: f
    type: u1
    enum: bool
    
  - id: g
    type: b1

[KOLANICH]

b1 is 1 bit, NOT byte. Your screenshot shows the correct parsing.

[durka]

Hmm... it does look like I misunderstood the type documentation then, I got tripped up because the b prefix is listed both under "integers" and "booleans", with the first one implying that the X in bX is the same units as the X in uX:

Integers come from uX, sX, bX type specifications in sequence or instance attributes (i.e. u1, u4le, s8, b3, etc), or can be specified literally.

So, how do I specify a one-byte field interpreted as a boolean, is the enum actually the correct thing to do?

I am still skeptical about the behavior where bX fields seem to "overlap" with the previous field, and nothing happens when you click on them. Is that intended?

[KOLANICH]

So, how do I specify a one-byte field interpreted as a boolean, is the enum actually the correct thing to do?

It depends. There are multiple ways to define a mapping from a byte to booleans. The most widespread one is the convention used in C: to consider 0 as false and anything else as true. The file format docs ideally must specify which way is used.

I am still skeptical about the behavior where bX fields seem to "overlap" with the previous field. Is that intended?

I don't understand what you mean.

[dgelessus]

The bX types are bit-sized integers, which are explained in more detail further up in the manual. As @KOLANICH already pointed out, the number behind the b is in bits, not bytes. The main use of bit-sized integers is for parsing bit flags or packed integers, where multiple small values are combined into a single byte. That is, if you have eight b1 fields next to each other, they correspond to the eight bits of a single byte.

Kaitai Struct doesn't have a built-in type for 1-byte booleans. This is in part because the format of byte-sized booleans can vary - usually 0 is false and 1 is true, but sometimes -1/0xff is used for true instead. The meaning of all other values also isn't clear - do other non-zero values also count as true, or do they generate an error?

There are multiple ways to parse byte-sized booleans with KS. One option is to use u1 and an enum, like you did in your original comment. Another option is to use bit fields to parse just the least-significant bit from the byte (which is the boolean value) and ensure that all other bits are 0:

meta:
  bit-endian: be
seq:
  - id: ignored
    type: b7
    valid: 0
  - id: the_bool
    type: b1

[durka]

OK thanks for explaining. I think I should close this issue except maybe for the UI issue where clicking a bit integer field doesn't select the containing byte in the hex view.