New feature in v3: cast!

Brian Candler B.Candler at pobox.com
Mon May 13 17:05:08 CEST 2013


On Mon, May 13, 2013 at 09:16:31AM -0400, Alan DeKok wrote:
> > 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.

I don't think we can guarantee non-overlap between attribute names and
enumerated values though. Example:

$ grep '^VALUE.*Session-Timeout' dictionary.*
dictionary.ascend:VALUE Ascend-Disconnect-Cause         Session-Timeout         100
dictionary.ascend.illegal:VALUE X-Ascend-Disconnect-Cause       Session-Timeout         100
dictionary.cisco:VALUE  Cisco-Disconnect-Cause          Session-Timeout         100
dictionary.rfc2866:VALUE        Acct-Terminate-Cause            Session-Timeout         5
dictionary.shiva:VALUE  Shiva-Disconnect-Reason         Session-Timeout         4
dictionary.starent:VALUE        SN-Disconnect-Reason            Session-Timeout         25
dictionary.starent.vsa1:VALUE   SN1-Disconnect-Reason           Session-Timeout         25
dictionary.usr:VALUE    USR-HARC-Disconnect-Code        Session-Timeout         7

Others are Idle-Timeout, NAS-Filter-Rule, Service-Selection (*).

So an example would be:

   if (Ascend-Disconnect-Cause == Session-Timeout)

In practice it would make little sense to compare an attribute which has a
defined enumerated values against a different attribute.  So here we must
mean the enumerated constant 'Session-Timeout'.

Of course, the dictionary value of this constant is different depending on
which LHS attribute we are comparing it to!

In fact, I think it would be sensible to *require* unquoted literals on the
RHS to be enumerated values.  Otherwise, imagine what happens if someone
writes this:

   if (Ascend-Disconnect-Cause == Idle-Timeout)

I would rather this errored than silently ended up comparing two different
attributes - which is almost certainly not what is intended.

Regards,

Brian.

(*) There are also a ton of DHCP attributes where there is an attribute and
a value with the same name, although I'm not sure how these attributes are
supposed to be used anyway.  e.g.

ATTRIBUTE       DHCP-ARP-Cache-Timeout                  35      integer
VALUE   DHCP-Parameter-Request-List     DHCP-ARP-Cache-Timeout  35


More information about the Freeradius-Devel mailing list