[Insight-developers] Analyze writer header size incorrect on 64-bit system

[kent williams]

Well you're right in that this code wouldn't work if sizeof int was 64 bit.

But there _should_ be some solution available.  The most obvious would be to
define the header in terms of data types of known size, EG int16 int32
long64, etc.  

Writing out binary structures to files isn't an isolated design failing of
NIfTI and ANALYZE file formats, and there's a tradition going back as far as
I've been programming (1982?) of carefully defining data structures so they
can be written and read directly to/from disk.

My point being, there was no 'luck' involved -- the structure was laid out
such that it would get read and written correctly on nearly all current
platforms.

It should be mentioned as well that ITK uses third party code for NIfTI
reading/writing -- no ITK develper wrote this code. Hans happens to be part
of the developer group for NIfTI, so if we come up with a solution to this
64-bit header problem, we can push it back to the official NIfTI library.

On 7/24/07 11:13 AM, "Sean McBride" <sean at rogue-research.com> wrote:

> On 7/24/07 10:42 AM, kent williams said:
> 
>> It dumps out the relevant offsets and sizes of all the header fields, both
>> for the Analyze and NIfTI headers.
>> 
>> If I run the following on OSX:
>> 
>> g++ -o analyseHeaderLayout analyseHeaderLayout.cxx
>> g++ -m64 -o analyseHeaderLayout64 analyseHeaderLayout.cxx
>> ./analyseHeaderLayout > 32Bit_Output
>> ./analyseHeaderLayout64 > 64Bit_Output
>> diff 32Bit_Output 64Bit_Output
>> 
>> I get these results:
>> 
>> 5c5
>> <     sizeof(long) = 4
>> ---
>>>     sizeof(long) = 8
>> 
>> Which is what you want to see < the only difference between compiling 32 and
>> 64 bit is the size of a long.
> 
> On Mac OS X, yes, that is the major difference; there are others though:
> <http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/
> transition/chapter_3_section_3.html>
> 
> In any case, the struct has no 'longs' so one 'lucks out' on Mac OS X.
> But on other systems 'int' is also 64 bit, and this code will be
> horribly broken there.
>