Multivalued attributes
Arran Cudbard-Bell
a.cudbardb at freeradius.org
Thu Jul 31 18:27:40 CEST 2014
On 31 Jul 2014, at 04:33, Alan DeKok <aland at 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 at freeradius.org>
FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140731/ff3577f4/attachment.pgp>
More information about the Freeradius-Users
mailing list