filters: strange protocol restarts

[Ondrej Zajicek]

On Fri, Sep 27, 2013 at 02:35:45PM +0300, Sergey Popovich wrote:
> There are at least one other caveat related to comparison, not covered by this 
> patch:
> 
>     How to determine if clist, eclist are empty? Statements like
>       bgp_community_list = -empty- or
>       bgp_ext_community_list = --empty--
>     gives filter runtime error. Same reason for comparing bgppath type
>     with +empty+ (i.e. bgp_path = +empty+), however for this we could
>     use something like bgp_path.len = 0)?
>  
>     Interesting thing about comparison I found in filter/test.conf2:
>       clist ~ [(*,*)]
>     but this is not documented.

It is documented:

Special operators include <cf/˜/ for "is element of a set"
operation - it can be used on element and set of elements of the same
type (returning true if element is contained in the given set), ...
or on clist and pair/quad set (returning true if there is an element of
the clist that is also a member of the pair/quad set)

> So I consider to submit my attempt to address this caveat and add some other 
> useful things related to comparison:
> 
>   * Move same_tree() for SET comparison and trie_same() for PREFIX_SET 
>     comparison into val_compare().

Well, that was my first idea w.r.t. the original problem with reconfigure, but
having nonsensical '<' offends my algebraic sense ;-) and there is no good
reason to imlement some consistent arbitrary ordering on such objects.

Good solution would be to have val_same(), which would work on all types
(and would be used where equality is tested), while val_compare would only
work on ordered objects.

You are right that pm_path_compare() already returns some nonsense.

>   * Split comparison to T_VOID in val_compare() in two parts, when types are 
>     equal (add case to switch) and when are not. Do similar in val_in_range().
> 
>   * Document -empty-, --empty-- and +empty+ special purpose constants.
>     Also document S.empty statement for use with dynamic attributes.

Well, these constants are not documented on purpose, as they are more
like ad-hoc constants for testing purposes, not much needed when you
have X.empty operator.

X.empty operator could be documented, i wanted to do it already,
the only problem i have with it is its name. When i see 'X.empty',
i would think that 'empty' mainly as adjective (predicate
for emptiness-testing), not as verb (operator of emptying).

Having some predicate that would return true/false whether the
path/list/set is empty would be useful, but both cannot be named
'empty'. Perhaps name the former 'reset'? Or keep current 'empty' and
use some other name for the predicate? Any comments on this?


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20130927/45a86a1f/attachment-0001.asc>