32 bit unsigned int not large enough, alternative data type?

[dvader0571]

I have a calculation that takes in the number of bytes for a given file. This number can be in excess of 4.2 billion (4.2GB) bytes, which apparently is the largest a 32 bit unsigned int (or ulong/DWORD) can handle. I can put these numbers into Excel and it calculates them fine. Is there a data type out there I am missing? The MSDN documentation appears to have none.

Or is there a trick to all this. Thanks for any suggestions.

 

[ArkM]

See (MSDN __int64 (MS C++ specific), or use doubles...
Don't forget about proper casting in expressions.

 

[Cagliostro]

Just curious, why do you need larger data type?

Ion Filipski

 

[teriviret]

Just a guess, but maybe he has large files in excess of 4.2GB?

 

[Cagliostro]

for processing files larger than 4.2Gb you don't need bigger integers than 32bit. In Win32API files are addresed by two 32bit integers, not one 64bit.

Ion Filipski

 

[teriviret]

Two 32 bit integers put together _is_ one 64 bit integer. That's why LARGE_INTEGER is defined using a union:

typedef union {
  struct {
    DWORD LowPart;
    LONG HighPart;
  };
  LONGLONG QuadPart;
} LARGE_INTEGER, *PLARGE_INTEGER;

 

[ArkM]

Binary representation of LONGLONG is the same as for __int64 type. To sum file sizes in a whole directory (or partition) we need more than 32-bits long. So MS presents its C type extension __int64. It's a normal integral type with all ops (there is I64 modifier in printf format specs...
Win API returns file size as 64 bit (in WIN32_FIND_DATA). It's more comfortable to work with __int32 type vars.

Slightly more careful approach: convert two 32-bit ints to double by hand (53-bit int surrogate). It seems it's the same degree of platform dependency as using __int64...

 

[ArkM]

Sorry, misprint: read to work with __int64 in my post above...

 

[dvader0571]

Hey guys, thanks for the info ill try _int64. The reason is this. I am using an algorithm provided my MS to find out how much physical hard drive space a database table takes. This way I can pre-determine how much free space will be needed to modify/add a clustered index. The largest so far is a table with 34 million rows and that adds to about 8GB. But when I do the math 8192 (size of page in bytes) * 2,099,074 (number of pages) the DWORD (or double) overflows. Instead of 17,195,614,208 it shows around 1 million or so.

I may just have to convert it to MB instead of bytes