On 31 Jul 2014, at 04:33, Alan DeKok <aland@deployingradius.com> wrote:
Herwin Weststrate wrote:
That would make the following two expressions different:
if (Attr[*] !~ /regex/) if (!(Attr[*] =~ /regex/))
In general, != and !~ should be the same as !(.. == ) and !(.. =~)
I don't think that's correct in this case. != is equivalent to attrA ⊄ attrB == is equivalent to attrA ⊆ attrB ! is a completely different operator (logical NOT), so I don't see it as being an issue that those two expressions aren't equivalent. It'd be great to use the proper set operators everywhere in FreeRADIUS, but I imagine the majority of users wouldn't have a clue what they meant. So we do the automatic translation based on the types of the operands. We already translate < to mean subset when applying to IP ranges. i.e. 192.168.0.1 < 192.168.0.0/24 Is true. I see this as another case of needing to do the implicit conversion from well known comparison operators to set theory operators.
First one is true if any of the attributes doesn't match the regex, the second one if none of the attribute match the regex. I would expect them to return the same. There might be some rule or lemma in mathematical set theory here, but I'm not really sure about that (especially since that would probably require explicit any/all-modifiers).
I'll try to remember my math. I'm sure I had this in one of my degrees.
I didn't cover it when I studied set theory, but that was really set theory light.
About a year ago I was working on a small filtering language for an API which required multi-valued attributes. We changed the use of >, <, <= and >= to yield to syntax errors when combined with multi-valued attributes, because nobody here really knew what they were supposed to do in this context.
Makes sense.
You can apply the same logic I described previously to any operator, and you'll get consistent and understandable results. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2