Carsten Haitzler (The Rasterman) wrote: > On Tue, 06 Sep 2005 17:29:30 +0200 Kim Woelders <[EMAIL PROTECTED]> babbled: > > >>Actually, I fixed this in the e16 versions of these functions *long* >>ago. I think the implementation there (e16/e/src/ecore_e16.c) is more >>efficient than the current ecore one, as it avoids the unneeded malloc() >>when sizeof(int) == sizeof(long). >>I did mention to raster that I believed there were 64 bit issues with >>this code, but he didn't agree, and I didn't persue the matter. > > > i don't rememebr that bit - mind you i did leartn my lesson about the long > thing for 32bit long (hahahah - nice pun) ago. i would be most surprised if i > made the msitake again. i caught it as it was about to be "fixed" wrongly too > today. i think we may have crossed wires as to which code particularly was not > 64bit clean - different bits of code. yeah - i know the malloc isnt that > efficient - but it beats special casing it in all calling code. you need to > copy it - and in todays libc's the malloc is not so expensive really. e17/efl > is insanely malloc heavy, and it's actually amazing how little it affects it. > Ok, now I am going to persue this one :) It seems to me that you say that we always have to malloc and copy. I say we only have to malloc and copy if sizeof(int) != sizeof(long). In my opinion it is worth while to avoid malloc/copy in this kind of low-level code, if possible.
/Kim ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
