How long long int works?

On a 32-bit machine maximum value an integer can store is 4,294,967,295 which is 2^32 -1. But long long int has a much larger maximum value!

How does it store more than 2^32-1 when the limit is 32bits?

Number of bits has nothing to do with it. All that 32-bit says is that the CPU can add 32 bits at a time in a single operation. The CPU also has a bit field that knows if it needs to carry a digit over.

Think about how you do addition. Normally humans can only add one digit at a time (e.g. 3 + 2, 7 + 6 etc.) That doesn't prevent you from adding larger numbers (e,g, 395 + 463, 10457 + 654 etc.) now, does it? The way you do it is you start from the right, add single columns of digits and apply the carry as needed e.g. if you were to add 395 + 463, you would start from the right columns and first add 5 + 3 and write 8, then add 9 + 6 and write 5 and carry 1 and then add 3 + 4 + 1 and write 8 and then write the result as 858. And you can do this with any large numbers, even though you only know how to add single digits at a time.

The CPU does the same thing, except instead of adding a single digit at a time, it adds 32 digits at a time and applies the carry bit if needed. Of course, this means the compiler needs to generate multiple add instructions when your data type is long long int, but that is what the compiler is meant to do.

In your system, what's the definition of long long int? If you don't know, then go to your compiler's INCLUDE directory and read limits.h. As for the standard, my copy is at work and I won't be able to read it again until Monday.

On my system (Win7 64-bit) I have MinGW gcc 2.95.3-6 in which a long long int is 64 bits long. From MinGW gcc's limits.h:

which translates to 9,223,372,036,854,775,807 signed and about twice that unsigned (calc fails me here).

IOW, there is no 32-bit limit. On 16-bit systems, a long int was still 32 bits long. No 16-bit limit there and then. No 32-bit limit here and now.

The 32-bit "limit" isn't a fundamental limit. You should think of it as a size that the developers of your compiler decided would be a convenient default. Usually, this just means that it's the best-supported on the assembly-language level. The only obstacles to using a larger integer type, then, are (1) the additional work required to compile it to assembly language, and (2) the performance penalties that you thereby incur.

The same way a 16 bit machine supports 32 bit data types - by using two machine words to represent the value.

While a 32 bit machine can handle 32 bit data directly by for example being able to add two values in a single instruction, when handling 64 bit data multiple instructions are required and these are automatically generated by the compiler.

So for example for add, the compiler would generate code to add the two least significant words, and if this generates an overflow indicated by testing the carry flag, it would add one to the most significant work of the result. That is perhaps three instructions rather than one.