New feature in v3: cast!

Alan DeKok aland at deployingradius.com
Mon May 13 15:16:31 CEST 2013


Brian Candler wrote:
> Ah, suddenly I see where we're going. If it had used a more Perl-PHP-like $
> I think I would have gotten it straight away.
> 
>   if ($Framed-IP-Address > 192.168.0.0/24) { .. }

  Yeah.  Except $ is already used for config-file expansions.

> Aside: with explicit variable reference like this, I think the update {...}
> syntax might become redundant.  e.g.  you could just have
> 
>   $Tmp-IP-0 := $Framed-IP-Address

  Hmm... that's a good point.  I'll look into that.

> An explicit tag could also allow the expression language to expand to
> cover eval, although minuses would have to be space-delimited:
> 
>   if ($Event-Timestamp - $Acct-Session-Time < $Tmp-Integer-0) { ... }

  Yes, probably.  But that's lower on the priority list.

> Yes I see, that's another way it could disambiguate attribute names from
> literals.  It's a bit odd, if something which you know to be an enumeration
> constant representing an integer, has to be quoted as a string.

  Not really.  PPP isn't a valid attribute name.  So it must be an
enumerated value.

> Having said that, things like
> 
>     Service-Type := "%{sql...}"
> 
> are presumably still going to be allowed, so string->constant lookups can
> take place dynamically.

  Yes.

> So thinking aloud, the rules might be:
> 
>   - a quoted string is a string
> 
>   - an unquoted bareword which parses as an integer or an IP address has
>     that type

  That's hard.  There can be overlaps between the syntax of the various
types.  It's easier to just demand that the types be explicit.

  I think the "getting rid of update sections" above is a good reason to
keep using "&" for attribute references.  In that case, the rules are
pretty simple.

- & is an attribute reference (except it can be omitted on the LHS for
backwards compatibility)

- everything else is type-specific
  - strings MUST be quoted
  - other types MUST NOT use single quotes
  - other types MAY use double quotes / back-ticks for later expansion
  - bare words for other types MUST be parsable as the type

  e.g. in v2, "Framed-IP-Address < 127.0.0.1" was stored as a string,
and parsed at run-time.

  Right now, it's split into a LHS (attribute reference), operator, and
RHS (string).

  It *should* parse && save the RHS, so that it doesn't have to re-parse
 it at run-time.  That's relatively easy to do in the new framework.

  Catching errors on startup is preferable to catching them at run-time.

  Alan DeKok.


More information about the Freeradius-Devel mailing list