[Bf-committers] Blender .blend file format and FileGlobal struct

[Kai Burjack]

Hello,

the problem with the 4 bytes not being written is now solved, thanks!
Turned out to be a problem with my program, of course. :-)

Kind regards,
Kai

2014-12-05 23:19 GMT+01:00 Kai Burjack <kburjack at googlemail.com>:

> Hello,
>
> I just subscribed to this mailing list, so a friendly "hello" first. :-)
>
> Currently, I am building a Java tool that produces .blend files for
> consumption by the Blender application.
> Looking at the C code and the struct definitions and the file
> "writefile.c" it really is a straightforward process.
>
> But, at one point I came to a halt, and that's when I want to write the
> FileGlobal struct, which the Blender source does with the function
> 'write_global' in the source 'writefile.c'.
>
> This struct, as defined in 'DNA_fileglobal_types.h', defines at its very
> beginning a char[4] followed by two short's.
> My tool writes data according to this exact struct definition, but somehow
> the .blend files written by the Blender application are exactly 4 bytes
> shorter (two times 2 bytes) there. Looking in with a hex editor it is
> exactly at that very beginning where that 'char subvstr[4];' and the 'short
> subversion, pads;' should be written.
>
> So, these are 8 bytes. 4 for the char array and 2 times 2 for the shorts.
> Now, the Blender-written .blend file here has only 4 bytes written, instead
> of the expected 8.
>
> I assume this is due to the fact, that compiler optimization kicks in,
> resulting in the char-array member being simply erased from the struct
> definition, because it is actually never read anywhere in the code.
>
> Only the char array is read, namely in the function 'read_file_version'
> defined in 'readfile.c'.
>
> Is this right?
> Otherwise I would not know how Blender falls short of writing the 4
> additional bytes there.
>
> Best regards,
> Kai
>