Undoc. comctl32 mem management functions
rob at codeweavers.com
Wed Feb 7 15:57:27 CST 2007
Felix Nawothnig wrote:
> Hi. comctl32 exports (undocumented) Alloc() and friends which call
> LocalAlloc => GlobalAlloc => HeapAlloc since it's doesn't use any
> fancy LMEM / GMEM flags... so shouldn't Alloc() call HeapAlloc()
> If Global/Local* behave different than Heap* on Windows - wouldn't it
> then be desirable to replace the Alloc()/etc. calls in our comctl32
> (we use it all over the place) by Heap*?
There are probably quite a few locations where it doesn't make a
difference, but there are also probably a few locations where it does.
Since it is easier to use the Alloc/ReAlloc/Free functions, why bother
changing them to the longer Heap* variants?
> Reason I'm asking: Since it's not documented the Free(NULL) semantics
> are not clear (although it's safe in our implementation) - and I'm
> wondering if we really want to internally use undocumented functions
> with unclear semantics when there is an easy (documented) way.
Well, I think it needs to be tested on Windows if Free(NULL) is valid
before changing the calls in comctl32.
More information about the wine-devel