New feature in v3: cast!

[Brian Candler]

On Sun, May 12, 2013 at 08:49:07AM -0400, Alan DeKok wrote:
> > I'm also not sure that casting the LHS to <cidr> is a clear way of achieving
> > this.  The LHS is, and remains, a single IP address.  The RHS is a CIDR
> > prefix.
> 
>   The issue is that the code does type-specific comparisons.  It's hard
> to know what's right for inter-type comparisons.
> 
> 	if (127.0.0.1 < 2)
> 
>   ???

Certainly. I'd hope this would raise a type-mismatch error, rather than a
Perl-style "guess how to convert the value".

Of course, Perl has different operators for different types (== for numeric
comparison, eq for string comparison) so it has a clear idea how to
coerce the arguments.

> > since the unquoted RHS literal can be unambiguously parsed as a CIDR prefix
> > anyway,
> 
>   Well... maybe.  What about:
> 
> 	if (Framed-IP-Address =~ "%{sql: ...") {
> 
>   Is the RHS a regex?  A CIDR comparison?  An IP address comparison?

As I see it, the problem is that the value is a string, but you want to
treat it as something else.  So I would be inclined to make the value
conversion explicit:

 	if (Framed-IP-Address =~ <cidr>"%{sql: ...") {

or more traditionally,

 	if (Framed-IP-Address =~ cidr("%{sql: ...")) {

>   I'm trying to say that the code needs *unambiguous* rules.  Ad-hoc
> rules work in some cases, and don't work in others.  So they can't be used.

I wholeheartedly agree.

>   See Wikipedia for "range comparison" (IIRC).  There are 20+ types of
> possible relationships for two ranges.  In contrast, integers just have
> 3 (and their negations).  ==, <, >  (and !=, >=, <=)
> 
>   It's much easier to just say define a "contains" operator for CIDRs.
> That way you can't even *express* the other types of relationships.
> Because they're not needed 99.999% of the time.  And if they are needed,
> use Perl.

I'm happy with the semantics of "contains". I would be surprised if the "=="
operator were used to express it though.  If =~ can't be used then I don't
really mind if a new operator has to be introduced.

Typed values are pretty easy to handle. The thing which makes RADIUS special
is the need to handle cases where the RHS is an enumerated value dependent
on the dictionary type of the LHS:

    Framed-Protocol == PPP

So things like

    PPP == Framed-Protocol

or

    Tmp-Integer-0 == PPP

are unlikely to work. (And hence the == operator is non-commutative anyway).

Regards,

Brian.