Hi,
playing around a bit with wine, i found a thing that is obviously a bug.
In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value "0x7FFF" is used to check for the boundary of a 32 bit integer. However, there should be used MAX_INT instead.
By the way: Looking at current MSDN, DPA and DSA looks rather documented than "undoc" :-)
Regards Sascha
P.S.: Please CC me on answers as i'm not subscribed here.
Sascha Cunz wrote:
In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value "0x7FFF" is used to check for the boundary of a 32 bit integer. However, there should be used MAX_INT instead.
I somehow doubt that this function will ever encounter an INT greater than MAX_INT... :)
Anyway, I agree that the current behaviour looks at least suspicious. It was implemented by Dimi Paun in 2002 (http://www.winehq.com/hypermail/wine-patches/2002/10/0313.html).
However, it seems it was or is just hiding another bug - I did some testing on Win95, Win98 and Win2k3 and I can't reproduce that behaviour - lists with >0x8000 elements seem to work just fine.
And since those functions are fairly generic and documented for several years now it's quite possible that third-party apps use them for arrays with more than 0x8000 elements...
By the way: Looking at current MSDN, DPA and DSA looks rather documented than "undoc" :-)
Right (they were undocumented for a long time though).
I'm working on it.
Felix
Hi,
In lines 1944 and 1977 of dlls/comctl32/comctl32undoc.c the value "0x7FFF" is used to check for the boundary of a 32 bit integer. However, there should be used MAX_INT instead.
I somehow doubt that this function will ever encounter an INT greater than MAX_INT... :)
you're of course right here.
Anyway, I agree that the current behaviour looks at least suspicious. It was implemented by Dimi Paun in 2002 (http://www.winehq.com/hypermail/wine-patches/2002/10/0313.html).
However, it seems it was or is just hiding another bug - I did some testing on Win95, Win98 and Win2k3 and I can't reproduce that behaviour
- lists with >0x8000 elements seem to work just fine.
And since those functions are fairly generic and documented for several years now it's quite possible that third-party apps use them for arrays with more than 0x8000 elements...
By the way: Looking at current MSDN, DPA and DSA looks rather documented than "undoc" :-)
Right (they were undocumented for a long time though).
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.
However, this is used from treeview.c. Where i encountered the problem inserting more than 0x7fff entries.
Sascha
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
-
Felix Nawothnig -
Sascha Cunz