master branch radius_xlat() expected behavior?

[Arran Cudbard-Bell]

On 13 Jul 2013, at 08:14, Alan DeKok <aland at deployingradius.com> wrote:

> Arran Cudbard-Bell wrote:
>> No the behaviour isn't correct. It was broken by 4b9be42a2f1b45e97ee12de0d412a4f65c750074.
> 
>  Which was in turn caused by the Attribute[n] code being deleted...

Sorry about that.

> 
>  I've pushed a fix.
> 
>  As another note, the "users" file entries no longer work:
> 
> bob	Cleartext-Password := "bob"
> 	Filter-Id := "Hello %{User-Name}"
> 
>  The Filter-Id attribute never gets expanded, and is always empty.  But
> this works:
> 
> 
> bob	Cleartext-Password := "bob"
> 	Filter-Id := "Hello"
> 
>  Just WTF is going on with the code?  It's as if the handling of
> strings in the server has been destroyed.

No, not really. This was a specific case for users file parsing. Part of the problem is
because we don't use asserts in the library files, a lot of functions just return NULL
on error. 

In this case pairmark_xlat was refusing to mark a pair for expansion, because it already
had a value and it shouldn't of. In the server library this would of been an assert,
and the issue would of been very obvious.

Maybe we could add support in in src/lib to write out errors using a
logging function, and pass something in when the server starts up. Then if people
want to use it as a library and don't want a bunch of crap being written to stderr/
stdout, they just don't set the logging function.

This is the same approach used by libtalloc.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team