Undoc. comctl32 mem management functions

[Felix Nawothnig]

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() directly?

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

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.

And besides - the comctl32 code is full of "if(p) Free(p);"...

Felix

[Michael Stefaniuc]

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() directly?
>
> 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*?
>
> 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.
>
> And besides - the comctl32 code is full of "if(p) Free(p);"...
> Looks like i need to add Free() to my redundant_null_check.pl Smatch script.

bye
	michael
-- 
Michael Stefaniuc               Tel.: [phone]
Sr. Network Engineer            Fax.: [phone]
Red Hat GmbH                    Email: mstefani(a)redhat.com
Hauptstaetterstr. 58            http://www.redhat.de/
D-70178 Stuttgart

[Robert Shearman]

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() 
> directly?
>
> 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.

-- 
Rob Shearman