Open XVilka opened 3 years ago
Rethink on the pf syntax to be more consistent and harmonious
I'm not that familiar with pf
codebase, but please be aware that the syntax right now is completely parsed by the pf
handlers, not by newshell. Actually, the grammar had to had some special workarounds just for pf
syntax, because there are some chars that are usually not presents in regular arguments (e.g. I remember (
and )
, if I'm not wrong).
We could also check the Kaitai specification as a good example of the data description language, in terms of formatting/printing of course, we don't need everything: https://doc.kaitai.io/user_guide.html#_expression_language
Another possibility is to drop pf itself as a data representation and use only regular types. For saying for example whether to print some value in hex or decimal, endian swap, etc., types could get some kind of annotations if needed.
And for ease of use, we could have a pf-like syntax that can be used to quickly define such types so if you do pf cQQ
(this is https://docs.python.org/3/library/struct.html since I don't know pf syntax) it could create a struct like
struct {
char m0;
unsigned long long m1;
unsigned long long m2;
};
as an intermediate step and print the contents of that struct interpreted at the current address.
Also note, that some format values are emitted in librz/core/carg.c
- print_format_values()
function.
pf.
nested struct/union name autocompletion (currently works only for the 1st level)t
command parsing but not in thepf
syntax, thus printing it fromtp
command is impossible since it usespf
commands for that.pf.
formatspf
syntax to be more consistent and harmoniousSee the
pf
implementation inlibrz/core/cmd/cmd_print.c
andlibrz/type/format.c