Re: [PATCH] avifil32: Use typed pointers in sizeof() (Coverity)

[Bruno Jesus]

On Sun, Jan 10, 2016 at 10:35 PM, Nikolay Sivov  wrote:
> Signed-off-by: Nikolay Sivov
>
> dlls/avifil32/api.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/avifil32/api.c b/dlls/avifil32/api.c
> index c71efb4..a88e3bf 100644
> --- a/dlls/avifil32/api.c
> +++ b/dlls/avifil32/api.c
> @@ -2332,8 +2332,8 @@ HRESULT WINAPIV AVISaveW(LPCWSTR szFile, CLSID * pclsidHandler, AVISAVECALLBACK
>  if (nStreams <= 0) return AVIERR_BADPARAM;
>
> - streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *));
> - options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *));
> - streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*streams));
> - options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*options));

Hi, Nikolay. What about AviSaveA? The structure of code is identical.
Also in the loop I used void * to get the next arg from the list,
could that be a problem?

Best wishes,
Bruno

[PATCH] avifil32: Use typed pointers in sizeof() (Coverity)

[Nikolay Sivov]

On 10.01.2016 19:02, Bruno Jesus wrote:
> On Sun, Jan 10, 2016 at 10:35 PM, Nikolay Sivov  wrote:
> > Signed-off-by: Nikolay Sivov
> >
> > dlls/avifil32/api.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/dlls/avifil32/api.c b/dlls/avifil32/api.c
> > index c71efb4..a88e3bf 100644
> > --- a/dlls/avifil32/api.c
> > +++ b/dlls/avifil32/api.c
> > @@ -2332,8 +2332,8 @@ HRESULT WINAPIV AVISaveW(LPCWSTR szFile, CLSID * pclsidHandler, AVISAVECALLBACK
> >  if (nStreams <= 0) return AVIERR_BADPARAM;
> >
> > - streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *));
> > - options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(void *));
> > - streams = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*streams));
> > - options = HeapAlloc(GetProcessHeap(), 0, nStreams * sizeof(*options));
>
> Hi, Nikolay. What about AviSaveA? The structure of code is identical.
> Also in the loop I used void * to get the next arg from the list,
> could that be a problem?

Yes to all that, thanks. I'll send v2 shortly. va_arg is not a problem
of course, and allocation works as expected too, it's mostly for
consistency and making it clearer to a reader what a used type is.
> Best wishes,
> Bruno