Re: [Gnustep-cvs] r31629 - in /libs/back/trunk: ./ Source/cairo/ Source/gsc/ Source/win32/ Source/winlib/ Source/x11/

[Eric Wasylishen]

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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev