Bug in dlls/comctl32/comctl32undoc.c

[Felix Nawothnig]

First of all: I sent a new DPA testsuite to wine-patches some hours ago 
(http://tinyurl.com/ddlp4) which tests DPA_InsertPtr() with both (nItems 
< idx < 0x7fff) and (0x7fff < idx).

Our behaviour does not match Windows in both cases (besides several 
other differences). The tests are marked as todo_wine for now.

Sascha Cunz wrote:
> Well, the "insert"-function uses the value 0x7fff as a flag to the 
> "set"-function (to set a pointer at the end of the list). So i guess, what 
> was actually meant is to check on equality to MAX_INT.

This 0x7fff is clearly wrong, DPA_APPEND (which is defined to be 
0x7fffffff) would make more sense but testing against it would be wrong 
too since any given index greater than the number of items should cause 
DPA_InsertPtr() to append it at the end (so we should just do
   idx = min(idx, nItems);
or something like that).

This behaviour is described at http://tinyurl.com/c7ete (unofficial).

Now, I'm not sure if DPA_SetPtr() has any special-case handling for 
DPA_APPEND but I doubt it (I guess I'll just add a check for it to the 
testsuite...)

> However, this is used from treeview.c. Where i encountered the problem 
> inserting more than 0x7fff entries.

Oh, I didn't know that we actually use those evil, undocumented 
functions. :)

Dimi: If you are following this thread - you wrote the code in question, 
do you still know how to reproduce these "problems in shell code" maybe?

Felix