On Thu, Sep 10, 2009 at 10:53:17AM +1000, Carsten Haitzler wrote: > On Tue, 8 Sep 2009 20:52:39 -0300 Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> said: > > you've already put my word in on this. i go the accounting way. 1. it is > consistent with eina_list. 2. can be extended beyond last and include count > and > many other things. 3. doesn't change inlist struct size to be bigger (tho we > dont win on it being smaller). 4. doesnt play evil games. (using low-order > bits > in pointers is wrong imho. i've sen this game played before (using high order > bits) and then it com crashing down on peoples heads when suddenly those used > bits become relevant. using those bits will also require instruction overhead > of masking them out always before use. so you lose on the code simplicity and > speed side, just to save 4 bytes (or 8 on 64bit) per inlist instance. it's not > worth it. it is possible also in future allocations no longer are limited to > word boundaries and allocs do use those bits, thus removing them from our use > and requiring another solution.
Does anyone know if the issues related to using the lower bits of pointers architecture-specific, libc-specific or both? I was pondering this recently in relation to a different project. I know that they use this technique in the Linux kernel. But obviously they have quite a lot of control over what their memory addresses look like in terms of alignment and thus unused bits. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
