crypt32: Avoid reading unitialized variables (Coverity)

[Frédéric Delanoy]

On Wed, Dec 14, 2011 at 14:58, Henri Verbeet <hverbeet at gmail.com> wrote:
> On 14 December 2011 14:54, Henri Verbeet <hverbeet at gmail.com> wrote:
>> On 14 December 2011 14:44, Michael Curran <curran.michaelp at gmail.com> wrote:
>>> Just a quick check, since Debian had a big kerfuffle when someone went
>>> and initialized variables in a crypto module, but is there any chance
>>> that those variables were left uninitialized on purpose?
>>>
>> Except for some TRACEs, I don't think these are actually read.
> And actually, that probably makes the patch wrong too. If those
> functions end up being called by an application you'd still be tracing
> uninitialized data, but Coverity just wouldn't notice.

They're only used in TRACEs since the passed pUsage (previous param)
is NULL indeed.
Coverity is actually OK reporting the "defect" since at least one path
(when tracing is enabled) prints the uninitialized garbage.

Should the TRACE (e.g. on crypt32:2435) be adapted so it conditionally
prints the value instead? Or be removed altogether?

Frédéric