On 2016-12-18 at 10:52:49 +0100, Vadim Kochan <vadi...@gmail.com> wrote:
> Extend proto field expression to:
>
> proto_field[{index}:{len}] = {func}
I like the idea behind this very much, but I'm not particularly happy
with the syntax of this.
First, I find it a bit confusing that the length is specified and not
the end index (as at least I would assume it i.e. like array indexing in
Python works).
Second, the need to mention a field twice with
something like:
eth(saddr=aa:bb:cc:dd:ee:ff, saddr[0]=dinc())
isn't very intuitive to understand IMO. And moreover, from the existing
syntax I'd assume some kind of function call semantics (like in C) with
the fields being parameters to the function. But indexing a function
parameter isn't really what I'm used to (but then again this is just
personal taste).
And third, it's not immediately intuitive to which item the index
refers, i.e. is the MAC address ab:bb:cc:dd:ee:ff afterwards or
aa:bb:cc:dd:ee:00?
But then I currently don't immediately see a better way to implement
this behavior and I also see why you'd chosen the indexing to work with
length rather than end index.
One option might be to let the user specify multi-byte/-word fields as a
C-array-like initializer list and support function calls therein, i.e.
the example above could be written as:
eth(saddr={ 0xaa, 0xbb, 0xcc, 0xdd, 0xee, drnd() })
which would be a bit more in line with the traditional trafgen syntax.
Let me think about this a bit more...
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to netsniff-ng+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
