_parent breaks when nested below a switch statement about kaitai_struct HOT 6 CLOSED

Thanks! From what I see so far, you're right, it's legit .ksy and probably a bug in parent type propagation in ksc. I'll look into it.

from kaitai_struct.

I've added new test (nav_parent_switch) and applied the fixes to compiler to make it run. It should be ok now: http://kaitai.io/ci/ shows that it passes, I'll add C# spec soon too.

I've updated http://kaitai.io/repl as well. Please check if it works for you :)

from kaitai_struct.

Looks good !

Here's my (on going) implementation of ASTERIX : https://gist.github.com/kouak/1c0317fa1293cfbe8195386820df5ec9

This file compiles fine on the repl.

from kaitai_struct.

Thanks! By any chance, would you want to contribute this implementation to https://github.com/kaitai-io/kaitai_struct_formats ?

from kaitai_struct.

I'd be more than happy to do so !

However the format I'm working relies heavily on non standard structures ... Some integers are coded on 3 bits (since their value is in the 0-7 range), multiple subfields are single bits. Once non-byte fields are baked into kaitai, I guess I'll consider moving beyond the "pet projet" status and possible use kaitai to generate a production grade parser.

Another issue is that this format is very wide. The gist I pasted above only treats a single category (CAT030). There are over 30 categories in ASTERIX. This leads to a side question : is there any way to split a format definition across multiple files ?

If you happen to be interested in this format, I could provide detailed specifications and support to exploit them, since they make extensive use of domain specific vocabulary (air traffic jargon mostly).

from kaitai_struct.

One of the big goals (and certainly a very ambitious one) envisioned for Kaitai Struct is to gather a free/open source library of file formats / protocols specifications. It would be fundamentally different from other projects like https://www.fileformat.info/ http://www.zamzar.com/fileformats/ http://fileformats.archiveteam.org/ in one simple way: we won't be just gathering text, human-readable specs and links to various ad-hoc implementations, but want to strive for having a formal spec in .ksy language, understandable by both humans and machines (compilable into the parsers in a variety of target programming languages).

In that spirit, of course any format descriptions are very welcome.

Some integers are coded on 3 bits (since their value is in the 0-7 range), multiple subfields are single bits. Once non-byte fields are baked into kaitai, I guess I'll consider moving beyond the "pet projet" status and possible use kaitai to generate a production grade parser.

Technically, if these values are always packed into bytes on the same bit places, you can use value instances right now to do that:

seq:
  - id: b1
    type: u1
instances:
  value:
    integer_in_bits_0_to_2:
      value: 'b1 >> 5'
    bit_3_as_int:
      value: '(b1 & 0b00010000) >> 4'
    bit_3_as_boolean:
      value: '(b1 & 0b00010000) != 0'
    integer_in_bits_4_to_7:
      value: 'b1 & 0b00001111'

is there any way to split a format definition across multiple files ?

Yes, it's already possible. Actually, you don't need to do anything special for that. You can just have several files with several top-level types, and you can reference one from the other:

format_a.ksy

meta:
  id: format_a
seq:
  - id: code
    type: u1
  - id: body
    type: format_b

format_b.ksy

meta:
  id: format_b
seq:
  - id: foo
    type: u1

For a working production example, take a look at how files in https://github.com/kaitai-io/kaitai_struct_formats/tree/master/network reference each other (pcap → ethernet_frame → ipv4_packet → tcp_segment).

from kaitai_struct.