!= and !~ operators

[Joe Maimon]

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 
modules.

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 
as possible.

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 
current usage.

Not like my opinion actually matters much.

> 
>   Alan DeKok.
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
> 
>