!= and !~ operators
jmaimon at ttec.com
Tue Nov 8 03:15:45 CET 2005
Alan DeKok wrote:
> The same thing goes for "==". Having the attribute not exist is
> technically an exception, not a failed match.
When you put it that way, it actually becomes clearer.
It seems to be quite unreasonable for == to return success if the
attribute did not exist. Indeed, it only returns match if there is an
attribute that exists and matches the supplied value.
So to != should only return match if there was no attribute that existed
and compared successfully with != value.
A requirement that the attribute existed but did not match the value is
not quite an inversion of ==
!* is properly an inversion of =*
>>I have tested it to an extent and would appreciate feedback.
> My main concern is changing the behavior of the server.
Does this mean you think the patch would be a good idea otherwise?
With some changes it can avoid changing the behavior of != !~ when no
pairs are found.
But is that a good idea?
Perhaps a small poll to find out if anyone present relies on the current
behavior of != ?
Anyways, I thought you were doing a 2.0.0 :-) ?
If the operator behavior is problematic, perhaps users would be best
served correcting it as early as possible in the server history.
So far I have seen -= , != , !* , !~ that could possibly be changed.
I also have added -* , -~ operators that I find usefull, especialy in
the policy module.
> I'd prefer to move these kinds of checks to rlm_policy, as it's new,
> and won't break existing systems.
The policy module, while I managed to get it to work for my own
purposes, wasnt being called complete or stable. And it stands to reason
that paircompare could/should be used by all modules who wish to
maintain comparable comparison rules as used in the users file and other
Also the policy manages to duplicate a nice portion of the paircompare()
functionality within evaluate_condition(). That means two sets of code
need to be maintained to present as consistent an experience to the user
Additionaly, != is handled the same way in the policy module as in
paircompare(), if it doesnt exist it returns FALSE.
I guess what I am getting at is the impression that equaly important as
being consistent with past usage should be internal consistency with
Not like my opinion actually matters much.
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
More information about the Freeradius-Devel