Open ErichDonGubler opened 5 years ago
You are absolutely right about this. Some of the main differences is that taikai uses rust notation for numerical primitive (i.e. u8 instead of u1 for a byte, ...).
Also if conditions in kaitai are represented in a python-like syntax if: foo and _parent._parent.bar
whereas taikai uses a rust expressions if: self.foo && _parents.1.bar
(note the self
and the different way to access parents - _parents
is a tuple in taikai where the nearest parent is the zeroth entry and the Nth parent is _parents.{N-1}
)
EDIT: also see https://github.com/manuels/netlink-wg/blob/master/src/netlink_generic.tsy for an example (it would be much nicer, one "switch-on types" are implemented.
It'd be great to avoid fracturing the ecosystem, though I'm not sure what tradeoffs you're attempting to make here. Would it be possible to eventually either make taikai
syntax a superset of Kaitai syntax, or perhaps have a mode where Kaitai logic is used instead?
Either way, this crate is interesting, and I'm glad somebody's spending time on it!
It'd be wonderful if we had some ecosystem backing for using
*.ksy
files! However, it's hard to tell what you mean by "Kaitai-like" in theREADME
. Does this mean that this crate accepts a syntax that is similar to but may be arbitrarily different from aksy
definition? Is there some realistic expectation of compatibility?