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  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  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