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