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.