[Bf-committers] ID Properties and 64 bits

Joe Eagar joeedh at gmail.com
Sun Apr 29 02:12:36 CEST 2007

Hrm.  Also, I'm thinking of creating two structs like so:
  struct IntArraySegment { int32_t a; int32_t b;}
  struct FloatArraySegment {float a; float b;}

. . .to use for saving arrays.  These structs would only be used in the 
file code, as DNA descripters of id property arrays.  They each have two 
members, since structs have to be multiples of eight.  This means that 
four bytes of the array's MemTail might be saved along with the array; 
despite being bad form, this shouldn't really cause any problems as 
those bytes would be ignored on file read.

The advantage of doing this is that then the file reading code can do 
all necessary endian switching code itself,  rather then me having to 
write code to do it manually.  Also, this should make things easier if 
id property arrays ever get switched to int64_t (like in the far future, 
when everyone has 64-bit machines and OS's :) ).

Joe Eagar wrote:
> Hi.  I'm working out how ID properties will work in 64-bit blender.  
> Currently I'm thinking that I should use int32_t 
> <http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html#gdb828ef50c2dbb783109824e94cf6c47> 
> to store ints, to avoid all kinds of conversion woes (for example, id 
> properties is a generic storage format, but what if someone stores a < 
> 4 billion number in a 64-bit id property and its loaded into a 32-bit 
> blender? should blender then use a long long instead of a normal int?  
> Better to just use 32-bit ints all around).
> Int32_t is a C99 datatype (defined in stdint.h) that defines a 32-bit 
> integer.  Most likely a wrapping header will have to be made for irix 
> and other platforms that are still at C89.
> This would of course mean adding int32_t 
> <http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html#gdb828ef50c2dbb783109824e94cf6c47> 
> support to makesdna.  While I'm add it, it may be a good idea to add 
> intptr_t support too.  Intptr_t is a C99 integer datatype capable of 
> holding a pointer; we discussed on irc a while back possibly using it.
> Joe
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list