Re: comctl32: Fix read of uninitialized data in LISTVIEW_GetItemExtT when LVIF_TEXT is not set (Valgrind).

[Nikolay Sivov]

On 2/19/2011 03:34, Alexander Scott-Johns wrote:

I think it's enough to add a mask check here:
---
     if (bResult && lpLVItem->pszText != pszText)
---

to keep a single call of GetItem.

comctl32: Fix read of uninitialized data in LISTVIEW_GetItemExtT when LVIF_TEXT is not set (Valgrind).

[Alexander Scott-Johns]

On 19 February 2011 11:42, Nikolay Sivov <bunglehead(a)gmail.com> wrote:
> I think it's enough to add a mask check here:
> ---
>    if (bResult && lpLVItem->pszText != pszText)
> ---
>
> to keep a single call of GetItem.

But isn't

     pszText = lpLVItem->pszText;

undefined behaviour if lpLVItem->pszText is not initialized?

comctl32: Fix read of uninitialized data in LISTVIEW_GetItemExtT when LVIF_TEXT is not set (Valgrind).

[Nikolay Sivov]

On 2/19/2011 16:49, Alexander Scott-Johns wrote:
> On 19 February 2011 11:42, Nikolay Sivov<bunglehead(a)gmail.com>  wrote:
> > I think it's enough to add a mask check here:
> > ---
> >     if (bResult&&  lpLVItem->pszText != pszText)
> > ---
> >
> > to keep a single call of GetItem.
> > But isn't
>
> pszText = lpLVItem->pszText;
>
> undefined behaviour if lpLVItem->pszText is not initialized?
> No, it's not undefined as long as you don't dereference it. Valgrind 
> catches condition that depends on this uninitialized value, not 
> assignment of course.

By the way, we even have a report for that - 
http://bugs.winehq.org/show_bug.cgi?id=24290