W dniu 19.05.2012 00:20, Phil Pennock pisze:
> On 2012-05-18 at 22:26 +0200, Marcin Mirosław wrote:
Hello!
>> Thanks for answer. May i ask for another review?
>> This reports are commented in the same way as report about dcc: "Stack
>> address stored into global variable"
>> http://mejor.pl/exim-4.77/report-IORFNM.html#EndPath
>
> This is $auth1, which is *checked* where it occurs in server_condition.
> That check is done while this function is in scope, in the OK branch.
> So the var is left dangling in the event that auth fails, but nothing
> will ever refer to it, so it's not a bug.
>
> If there's another authentication attempt, the variables will be reset
> first, so this can never be referred to in its current form.
>
> It's still a little cleaner to not leave a global variable pointing to
> invalid memory, even if it won't be referenced, so I've cleaned that up.
>
>> http://mejor.pl/exim-4.77/report-thpTB0.html#EndPath
>
> iplookup, only used at Cambridge, its use discouraged. Which would be
> why problems have not arisen elsewhere; it's a Router, so something
> referring to the expansion variables in a later Router is a mistake, so
> people aren't writing such configs and we're not being bitten.
>
> Looks like it's worse, as all the expansion variables will be pointing
> to it.
>
> So it requires a broken config to reference these, but it's still bad
> for us to make it too easy for a broken config to cause a crash, so I've
> fixed this too.
>
>> http://mejor.pl/exim-4.77/report-kWMaKG.html#EndPath
>
> Not a problem. This is a function only called by -bmalware, so Exim
> exits after calling it, and the variable can never be referred to.
>
> If these are the only complaints though, it's worth silencing the
> message by resetting message_id to NULL afterwards.
>
>
> So: one absolutely not a problem, one almost certainly not a problem,
> and one which is a problem but requires a strongly-discouraged router
> designed for one specific environment, *and* a broken config, to
> trigger.
>
> Will push in a moment.
Thanks for all fixes and explanaitions. It's good news it was small
chance to hit problem.
I don't know if you do clang analyse from time to time so i'd like to
ask is it worth me to do clang analyse before/after each release or is
it too rarely usefull?
Marcin
