Matching a prefix in huntgroups file

[Alan DeKok]

On Nov 9, 2016, at 2:32 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> 
> No absolutely not. Magic typing is the work of the devil. You force the author to cast an untyped LHS and bomb out if the cast fails - at compile time for constants, runtime for dynamics:

  Yes.

> if ('10.254.0.0/16'::ipaddress contains &NAS-IP-Address)
> 
> if (&Tmp-String-0::ipaddress ...)

  Yeah.  That's not nice.

> OT: remind me why & is now a thing in front of unlang attribute names, as opposed to defining barewords as attributes?

  Because attribute names can be mostly anything.  And magic typing strings as attribute names is hard. :)

  Part of the issue is legacy compatibility.  The parser always allowed bare strings, and then figured out (mostly) which ones were attributes, and which ones were not.  And it got that magic typing wrong.

  So... &Foo is *always* an attribute reference.  /foo/ is *always* a regex.  "foo" is *always* an expanded string.  'foo' is *always* a constant string.  And bare words are... of the devil.

  If the LHS is (say) integer, the RHS bare word is a number, and parsed as such.  If the LHS is an IP address (cast or attribute), the RHS bare word is an IP address, or maybe a CIDR.

  If both sides are bare words, who knows what the heck they ware.  So they're treated as strings.

  We *could* allow bare words on the LHS and things on the right:

	if (10.1.2.3 == &NAS-IP-Address)

  The interpreter in v4 is a lot more flexible than v3, and can handle this.  The parser can mostly handle it, too.  We just have to add some tests to be sure it works, and continues to work.

  But this:

	if (10.1.2.3  10.1/16)

  is the work of the devil.  No one knows what either side of the expression really is... so all guesses are wrong.

  Alan DeKok.