[sleuthkit-developers] Re: 64 bit compatibility of fstools

[Brian C. <ca...@sl...>]

On Mar 2, 2004, at 5:26 AM, Michael Cohen wrote:

> Hi Brian,
>    I tried to compile the sleuthkit on an opteron today with negative
> outcomes. The first problem is the _llseek function defined in 
> myseek.c is
> not compatible for the opteron since OFF_T is already 64bits, a simple 
> lseek
> can be substituted for myseek().

I think OFF_T is always 64-bits on new Linux kernels, even if you have 
a 32-bit processor.  I didn't realize that the seek function was fixed 
though (I hadn't even thought of this problem until you mentioned it 
actually).

See if there is a compile time variable that is set for 64-bit hardware 
and use that in fs_tools.h to set the USE_MYLSEEK, HAVE_LLSEEK, and 
LSEEK variables.

> ( Yeah i know the comment just above the code said:
>  /*
>   * This is LINUX, live on the bleeding edge and watch your software 
> break
>   * with the next release...
>   */
>   Looks like this is the time when things break)

This is all legacy TCT stuff and I've actually never looked into the 
details of the Linux seek system calls.

>   Secondly, the code seems to be peppered with things like:
> 	fs_dent->path = (char *)(int)begin + 1;
> where begin is char *.
> 	I am not sure what the purpose of the double cast here is but the 
> compiler
> spits out lots of warnings, and the program crashes at random places
> (possibly due to this kind of casts).

Interesting.  The reason is that we want the address contents of 
'begin' and some compilers will complain if you do not first mask it to 
an int before adding 1 to it.  What warnings do you get?  It could be 
because the address is actually a 64-bit value, but the int is still 
only a 32-bit value so it is truncated.... I guess the code could be 
written as

(char *)( (int)begin + 1);

I'm not sure if that would remove your warnings, but there still could 
be the 32 vs 64-bit address problems.

> Are there plans to make the code 64 bit safe? and what is the best way 
> to
> do so?

I have no clue.  I have never looked into this before.  I did have 
plans to go through the TSK code before v2 is released and get rid of 
the use of OFF_T and ADDR_T values and replace them with u_int32 or 
int64_t variables so that the code is more portable across platforms 
that have different sizes for off_t or addr_t.  Maybe other changes 
will also need to occur.  I don't have access to such a system, so I 
can't do much for testing or debugging  :(

brian