Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Validation and valid expressions #944

Open
krisutofu opened this issue Dec 31, 2021 · 8 comments
Open

Documentation: Validation and valid expressions #944

krisutofu opened this issue Dec 31, 2021 · 8 comments

Comments

@krisutofu
Copy link

krisutofu commented Dec 31, 2021

In an internet search I found the Github issue that proposed the valid key and looked into the code to ensure it is there.

I used valid to ensure that a file offset is 16-byte aligned. (Btw, if there is a way of doing it in an imperative manner, please tell me.)

Is the lacking documentation intended, because experimental feature, or could people just try to PR addtions to the documentation?

At the moment, there are five specific expression keywords used in ValidationSpec.scala : min, max, eq, any-of, expr.

@KOLANICH
Copy link

Is the lacking documentation intended, because experimental feature, or could people just try to PR addtions to the documentation?

Feel free to contribute the docs. I remember I am using this feature for pretty long time.

@krisutofu
Copy link
Author

krisutofu commented Jan 2, 2022

This is awesome. I didn't spend much time looking into the code. Is a "reverse solver" in service for valid-expressions to yield imperative meaning? This would be great! And definitely a useful replacement for an exception throwing mechanism.

If so, I'll adjust the text for my following documentation PR.

@KOLANICH
Copy link

KOLANICH commented Jan 2, 2022

Is a "reverse solver" in service for valid-expressions to yield imperative meaning?

I don't fully understand what you mean. Do you mean serialization? Automatic serialization is not yet implemented.

@krisutofu
Copy link
Author

krisutofu commented Jan 2, 2022

Yes, I meant using valid as a logic-programming facility, which generates serialization code which satisfies the formula at runtime or throws an error if impossible. Although it would be a cutting-edge feature, it's probably low priority, if desired at all.

Generally, formula satisfaction is difficult because predicate logic satisfaction complexity is in PSpace but I believe most practical cases are not worst-case complex. All types in Kaitai-Struct are finite at a point of time so that it is decidable at runtime.

@KOLANICH
Copy link

KOLANICH commented Jan 2, 2022

It is one of the long-term goals to automatically derive serialization code. See #27 for more info.

@krisutofu
Copy link
Author

I forked Kaitai Struct Doc and pushed my branch to it. What do I need to do now?

Here it is:
https://github.com/krisutofu/kaitai_struct

New branch name is 944-valid-documentation.

Btw, I didn't succeed in building the doc with Makefile because of missing raw/pygments.css and docson/*

@krisutofu
Copy link
Author

krisutofu commented Jan 2, 2022

It is one of the long-term goals to automatically derive serialization code. See #27 for more info.

Yes, a complicated topic. But it's possible at the moment to just save the Kaitai struct representation to a file and throwing an exception if it doesn't verify the parsing rules, right?

@KOLANICH
Copy link

KOLANICH commented Jan 2, 2022

Currently serialization to some very minor extent is implemented only for Java target (if I remember right - in a separate branch) + python Construct library has something like that, and there is a target for emitting code for Construct. But IDK if dependencies between fields are implemented and I guess they are not, so if you modify an array which length is
stored in another field, I guess you have to update the length manually. Not sure though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants