Hey, I can revert the change if needed, sorry if it was premature. I made the change based on David marking the objc_malloc and related functions as deprecated in libobjc2 (they're not exported in the headers, so using them on x86-64/linux could cause memory corruption since function calls with no declaration are compiled to return ints). In libobjc2, we should add all of these deprecated functions to the headers with __attribute__((deprecated)), because many are still used in GS..
My personal stance is that I favour simply using malloc when it is sufficient - it makes code easier to read, because you know that nothing is going on behind your back. I find that malloc is almost always used in ObjC for storing a buffer of primitive C data types, rather than object pointers. Eric On Nov 20, 2010, at 7:33 AM, David Chisnall wrote: > On 20 Nov 2010, at 14:25, Nicola Pero wrote: > >> If boehm garbage collection is being used, I can't see a particular reason >> to manage C memory manually using malloc() and free(); >> using objc_malloc() and objc_free() (btw, objc_free() is an empty operation >> in that case) provides garbage collection for C memory >> too, and makes sure that you don't crash because you forget that you have a >> reference to an garbage-collected Objective-C object >> in your C memory. > > If using the Boehm GC, then you are using the GCC runtime. In this case, > NSAllocateCollectable() will be using objc_malloc(). If using the GNUstep or > Apple runtimes, objc_malloc() is not implemented, and we have no way of > distinguishing whether objc_malloc() should wrap NSAllocateCollectable() with > the scanned option, without the scanned option, or malloc(). > > David > > -- Sent from my PDP-11 > > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
