xlat expansion of absent VPs

[Alan DeKok]

Phil Mayers wrote:
> I don't understand what the problem with that is; can you elaborate on
> it for me?

  In general, silently omitting expected values is bad.  It means that
the string being printed doesn't have the number of fields you want.

> In "exec" situations, FreeRADIUS has split the string into argv before
> it does each xlat, so you don't get a missing argument - you get an
> empty one, which is legal.

  It works there.

> In SQL, you get an escaped string surrounded by ''. Sure, if you omit
> the '' then you're in trouble, but nothing can stop that sort of
> brokenness (well, SQL param binding, but we don't have that)

  It works there.

> I don't really like the idea of expanding to a special/magic value, or
> of aborting on a missing value.

  It's safer than (say) the linelog module suddenly printing 4 columns,
when you expect 5.  That's the worry.

 Expanding to an empty string *sometimes* works.  But in *general*, it's
not safe.  No one complained in v2, but maybe it's just that no one noticed.

> Couldn't we have:
> 
> %{notempty:%{Var}}
> 
> ...which fails the entire xlat somehow, for variables which *must* be
> present?

  Maybe.  I'll take a look.

  For accounting, it seems that the better approach would be to use
filtering in the update sections:

	update request {
		Acct-Input-Gigawords >= 0
		Acct-Output-Gigawords >= 0
		...
	}

  So that if attributes are omitted, that "update" section adds them
with "0" values.

  The later code (SQL, etc.) then no longer needs to check: the
attributes are always there.

  Alan DeKok.