Author Topic: Further issue with file size > 4GByte on 32bit  (Read 1554 times)

Offline ralph

  • Jr. Member
  • **
  • Posts: 7
    • View Profile
Further issue with file size > 4GByte on 32bit
« on: April 20, 2015, 19:22:41 »
Last week I posted this: http://forum.loggytronic.com/index.php?topic=757.0. Thx a lot for the fast feedback.

Now I tried to understand what went wrong and I found that one problem is the variable type (always 32 bit) while the ftell will only fail on 32-bit systems as the long argument is only 32bit wide there while on 64-bit systems the long argument is 64-bit wide. I had a look for similar issues and found another one in recplayer.c:

Code: [Select]

void RecPlayer::scan()
{
   .....

   segments[i] = new Segment();
   segments[i]->start = totalLength;
   fseek(file, 0, SEEK_END);
   totalLength += ftell(file);    // ftell will return a 32-bit (signed) value on 32-bit systems 
   totalFrames = indexFile->Last();

  .....

The ftell returns a long which is fine on 64-bit systems while the call will return a 32-bit trunated value on 32-bit systems. Since it returns a signed value the result may become even negative!

I suggest that you use ftello instead of ftell. And perhaps switch completely to fseeko even for the working call before ftell.

By the way: Why is the segments[0] array member never used? In C++ counting typically starts at 0.

Offline MartenR

  • Hero Member
  • *****
  • Posts: 788
    • View Profile
Re: Further issue with file size > 4GByte on 32bit
« Reply #1 on: April 21, 2015, 07:15:15 »
The ftell is already an ftello in the scraper_support branch in git.
Please use for further testing the development branch scraper_support, both on client and server side.
It will soon lead to an release.

The segments corresponds to the files of the recording, their number starts at 1.
That is the reason.

Marten