Isn't the assumption that sizeof(int) = platform type in bytes (e.g. 4 for 32-bit and 8 for 64-bit platforms)? I expected int on 64-bit platform to be 8 bytes in size.
You'll see this typically listed as a LP64 model. The other common option is ILP64, where int == long == long long == void * == 8.
It should also be noted that this has nothing to do with the underlying hardware. Instead it's a decision made by the OS ABI. There's nothing that says you can't have sizeof(int) == 8 on a 32-bit system.
While it has nothing to do with hardware per se, ILP64 is often seen on platforms, where some significant 32 bit operations (often memory accesses, but surprisingly sometimes even ALU ops) are (or used to be) slower than 64 bit.
It depends on your platform AND on your compiler, so just saying "Windows 64" isn't enough information. Conceivably, there are compilers for "Windows 64" such that sizeof(int) == 8.
Your point (that int isn't a qword on all 64bit architectures) still stands. But your statement is potentially incorrect.
The OS ABI basically defines what the compiler will do. While it's possible to run a compiler in ILP64 mode on Windows 64, you won't get too far if you try to pass a 64-bit integer >4^32 into a Windows system call.
... or pass any 64-bit integer. Windows API calls are mostly "stdcall" and use stack for parameter passing - pushing 8 bytes instead of 4 could be disasterous in many ways - especially considering that the callee cleans the stack in this case.
There is no stdcall/ccall distinction on 64-bit Windows, there is only one ABI convention that sadly uses a different set of registers for parameter passing than Linux. Only the first four parameters uses registers, the rest is passed on the stack.
Even on 64bit machines an int has 4 bytes. I don't think this is mandated by the standard, though. I guess that many implementations believe that this is better than having a huge size difference between 32 and 64 architectures. There is always long int if you want a 64bit integer.
