OpenEuphoria

Re: 64 bit integers (accessing files > 4Gb)

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jan 31, 2007
• 531 views

Chris Bensler wrote:
> 
> Matt Lewis wrote:
> > 
> > CChris wrote:
> > > 
> > No, definitely do *not* use cdecl for calling the Win32 API.  Otherwise,
> > your directions are correct.  I've used these functions before, and you
> > can simply break up the LARGE_INTEGER into two 32-bit integers.  You
> > just have to 'manually' do the 64-bit math and increment the high
> > dword yourself.
> 
> Thanks guys. That's what I thought. I already implemented that method before
> posting and it apeared to work, but I have no files large enough to verify.
> 
> Will an atom sufficiently store a large integer without loss of accuracy?
> I'd rather not have to deal with increments.
> Some basic testing shows that an atom will accurately store integer values up
> to about 8 or 9 Petabytes.
> 

Up to power(2,53)-1, the answer is yes.
However, SetFilePointerEx() won't understand if you pass it a double.

> Another question.
> I assumed that remainder(li,#100000000) would result in the lo dword, but
> apparently
> not. Is that bit of code wrong? Does remainder() not handle values that large?
> lo_word = remainder(long,#10000) works.
> 
> lo = li - (hi*#100000000) seems to be correct, but requires first calculating
> the hi dword.
> 
> Last Q:
> Is the lo dword signed or is the high dword?
> 

Both. In 16 bit world, -4 is FFFC: FF is signed (-1) and FC is signed (-4).
Same in 64 bit world with more bits.

CChris

> 
> Chris Bensler
> ~ The difference between ordinary and extraordinary is that little extra ~
> <a href="http://empire.iwireweb.com">http://empire.iwireweb.com</a> - Empire
> for Euphoria