crypt32: Avoid reading unitialized variables (Coverity)

[Michael Curran]

2011/12/13 Frédéric Delanoy <frederic.delanoy at gmail.com>:
> CID 4647-4648
> ---
>  dlls/crypt32/cert.c   |    2 +-
>  dlls/crypt32/encode.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/crypt32/cert.c b/dlls/crypt32/cert.c
> index 63107e1..ee96abd 100644
> --- a/dlls/crypt32/cert.c
> +++ b/dlls/crypt32/cert.c
> @@ -2554,7 +2554,7 @@ BOOL WINAPI CertAddEnhancedKeyUsageIdentifier(PCCERT_CONTEXT pCertContext,
>  LPCSTR pszUsageIdentifier)
>  {
>     BOOL ret;
> -    DWORD size;
> +    DWORD size = 0;
>
>     TRACE("(%p, %s)\n", pCertContext, debugstr_a(pszUsageIdentifier));
>
> diff --git a/dlls/crypt32/encode.c b/dlls/crypt32/encode.c
> index 05a3558..143ef0a 100644
> --- a/dlls/crypt32/encode.c
> +++ b/dlls/crypt32/encode.c
> @@ -768,7 +768,7 @@ static BOOL WINAPI CRYPT_AsnEncodeExtensions(DWORD dwCertEncodingType,
>         ret = TRUE;
>         for (i = 0, dataLen = 0; ret && i < exts->cExtension; i++)
>         {
> -            DWORD size;
> +            DWORD size = 0;
>
>             ret = CRYPT_AsnEncodeExtension(&exts->rgExtension[i], NULL, &size);
>             if (ret)
> --
> 1.7.8
>
>
>

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?