[Bf-committers] Post-2.40 release AMD64 question (re: shadbuf.c)

[Ton Roosendaal]

Hi,

And an additional note; it's best to limit the use of POINTER_TO_INT  
macros to the absolute minimum, to patch cases where the code abuses  
storage of pointers. Where ever possible, the long should be used in  
the code instead (except for structs being saved in files).
The macro hack only allows to allocate up to 32 GB, which is a limit we  
can't reliably live with forever. :)

BTW: I've not had a confirmation from a Windows guru/dev if there's a  
trick to make windows compiling conforming the LP64 standard. If  
there's no elegant solution for it, we might have to check on another  
good cross platform available keyword for denoting an "integer value  
that can store a pointer".
That will also result in work on the core file reading and dna stuff in  
Blender, has to be very carefully done. :)

-Ton-


On 30 Nov, 2005, at 1:56, Ken Hughes wrote:

> Thought I'd ask while it was still fresh in my mind:
>
> While going through the code looking for 64-bit issues, I came across  
> this code in RE_initshadowbuf():
>
> shb->zbuf= (unsigned long *) MEM_mallocN(
> 	sizeof(unsigned long)*
> 	(shb->size*shb->size)/256, "initshadbuf2");
>
> The code seems to work fine on 64-bit platforms.  However, it also  
> means the shadow buffer is 4 times larger than on 32-bit systems.
>
> Since the each entry in the buffer is either a pointer to  
> MEM_mallocN()'d memory or a 32-bit int (an RGBA color), seems like  
> this would be a good candidate for Ton's POINTER_TO_INT  
> /INT_TO_POINTER macros (and declaring the buffer unsigned int).
>
> Nod if you agree :-)
>
> Ken
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org