Security Update 2005-007 v1.1 Released

[AidenShaw]

64-bit integer arithmetic is very rare in 32-bit processors. (Do you know of any examples?)

Any file system with UNIX semantics that supports more than 4 GiB files must use 64-bit integers to specify the file offset in the "fseek" operation.

Internally, filesystems that support more than 4 GiB files will be using 64-bit integers for file sizes. In the Win32 API all file lengths and offsets are 64-bit integers.

System times are often 64-bit integers.

Then why discuss floats when I was talking about integers beforehand?

I was discussing the perception that many people have that 64-bit arithmetic requires a G5. It does not, a G3 and a G4 can do 64-bit arithmetic.

We both know that 64-bit float arithmetic is ubiquitous, and it's a subset of "64-bit arithmetic", that is - integer arithmetic, that needs a G5 (or other 64-bit CPU).

This is because programmers make a point of not using 64-bit integers in timing-critical sections of their applications.

When 64-bit processors become universal, you'll see that trend change. Once 64-bit integer math can be done in a single clock (the way 32-bit math is done today), you'll see programmers use the type all over the place. This will result in code that, if compiled for a 32-bit chip, will end up with performance penalties.

You'll see 64-bit become more common, but some programmers will realize that 64-bit (even in a single tick) needs twice the memory and twice the memory bandwidth of 32-bit integers.

Smart programmers won't automatically promote everything to 64-bit, they'll continue to use 32-bit and 16-bit integers where appropriate.