Hi Pablo, On Thu, Aug 30, 2018 at 12:24:11PM +0200, Pablo Neira Ayuso wrote: > On Wed, Aug 29, 2018 at 04:23:27PM +0200, Phil Sutter wrote: > > diff --git a/doc/libnftables-json.adoc b/doc/libnftables-json.adoc > > index 309988bcf02af..c174a35487d46 100644 > > --- a/doc/libnftables-json.adoc > > +++ b/doc/libnftables-json.adoc > > @@ -577,8 +577,6 @@ processing continues with the next rule in the same chain. > > Operator indicating the type of comparison. > > > > ==== OPERATORS > > -The operator is usually optional and if omitted usually defaults to "==". > > -Allowed operators are: > > > > [horizontal] > > *&*:: Binary AND > > @@ -592,6 +590,17 @@ Allowed operators are: > > *>*:: Greater than > > *<=*:: Less than or equal to > > *>=*:: Greater than or equal to > > +*in*:: Perform a lookup, i.e. test if bits on RHS are contained in LHS value > > Applied, but only one comment on this one, 'in' maps to the internal > implicit operation? I'm a bit confused about this one. No worries, it *is* confusing. :) In standard API we have this implicit op which we internally treat as OP_EQ with one exception which is bitmask on RHS. IIRC, treating absense of "op" property differently from it being there with value "==" was deemed inappropriate for JSON API. So I had to find an alternative to implicit OP just for the bitmask case, so I made up "in". If you have a better idea for this, I'm all for it. IMHO the real issue is that shortcut from 'expr1 & expr2 != 0' to 'expr1 expr2', although it is quite intuitive in practice. Actually, I could just drop the "in" operator and force users to build that lookup manually. Not sure if that's the better option. Right now it is at least a bit unclear when to use "==" or "in", mostly due to lack of documentation. Cheers, Phil
