Arran Cudbard-Bell wrote:
If the result of the condition cannot change during the processing of a request the condition is not evaluated during the processing of a request.
if ('foo' == 'foo') {
}
Will always be true, so there's no need to strcmp foo and foo on every request.
I just pushed a fix for that. Including unit tests. <woo>!
Doesn't contain a % surely?
Yes.
I meant:
${foo} -> %{User-Name}
That should just be a string substitution.
Sure there was just no indication to show whether the evaluation was actually being skipped, it looked like it was still being performed, when as you say 'User-Name' is always true.
The evalaution wasn't being skipped (until my recent patch). It was always being done.
Yep, that's correct, i'm not questioning the results of the evaluations they're all as I would expect. I was just pointing out that it's not clear that the condition isn't actually being evaluated.
The conditions *are* being evaluated. But not any more.
I'm aware of that. It makes it much easier to comprehend what's going on when you think of ${} expansions as doing something to C preprocessor macros.
Yes.
It's just the output didn't look any different for conditions I expected to be pre-evaluated.
Because they weren't.
If it's all happening transparently behind the scenes then that's fine.
With the changes I pushed, if you have: if ('foo' == 'bar') { ... } The entire block *disappears* from the run-time configuration. You will *never* see the "if" section being evaluated. The "if" condition is evaluated when the server loads, and the block is skipped. i.e. not even compiled. Which means you can do: if ('never' == 'always') { # FALSE! roses_are_red violets_are_blue freeradius_is_great and_so_are_you } And the server will start up correctly, and run. Even though there's no module called "roses_are_red". The server notices that the block is useless, and ignores it completely. Alan DeKok