Re: Undoc. comctl32 mem management functions
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
Re: Undoc. comctl32 mem management functions
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.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Undoc. comctl32 mem management functions
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
