I see very little point of using the 'int32_t' compared to 'signed int'. The project irrLicht actually shows one valid example for it in .\irrTypes.h:

#if defined(_MSC_VER) || ((__BORLANDC__ >= 0x530) && !defined(__STRICT_ANSI__))
typedef unsigned __int64            u64;
#elif __GNUC__
#if __WORDSIZE == 64
typedef unsigned long int           u64;
#else
__extension__ typedef unsigned long long    u64;
#endif
#else
typedef unsigned long long          u64;
#endif

MSDN writes little about the 'fixed size' data types it supports, such as __int32:
"The types __int8, __int16, and __int32 are synonyms for the ANSI types that have the same size, and are useful for writing portable code that behaves identically across multiple platforms" -- Great, it's "ANSI principle", I suppose.

I guess my point is; why does MSVC declare the data types prefixed with "__" a fixed size, yet \most\ other compilers determine the globally used "int"(etc.) as a fixed size? Is there any scenario that I should dread about a non-fixed size integer?

Edit: I am aware that 'int' on a x86 build is 32 bits, yet should be 64 bits on a x64 build.

The point is that you know that this type has 32 bits. Whereas for signed int you only know that it is at least the size of short, which is at least 16 bits. It might be 16, 32, or 64 bits. Or something else.

Sometimes it just doesn't matter what exact size a variable has, but sometimes it does. Using types like int32_t is a standard, portable way of being sure.

Similar is often done for various APIs, for example types like DWORD, HANDLE, or GLint. This, too, is for portability (and compatibility), but in this case in the exact opposite way. Whatever the real type is is completely opaque to you. You need not know and you don't want to know. If the API changes, they'll just change the typedefs, and your source code will still work the same.

Alright, I see. If you're expecting your plain int has at least 32 bits of storage, however, the platform it's being deployed on creates only 16 bits of storage.

So if you are performing a bit shift operation to take the last 16 bits out of the supposed 32 bits, bam.

Thanks!

Not at least, but exactly.

If you want at least, you can use int_least32_t or int_fast32_t

(The former guarantees at least the specified width, and the latter guarantees the fastest possible type while guaranteeing at least the specified witdth. Usually they're all identical, but not necessarily so!)

int32_t guarantees that you get exactly what you ask for, no bit more and no bit less (irrespective of what C type this corresponds to on your platform, so you can for example use that type on two platforms and be sure that a struct that you send over the network from one machine to the other will have elements of the exact same size -- this still leaves pointers and endianness as a problem, but those are different stories, as far as size is concerned, you're good).

And the code runs on 32 bits machine the x memory will start at the 5th byte while in a 64 machine it would start at the 9th byte. In this example you would surely run into a bug and very likely into a seg_fault.

This ain't necessarily so. In MSVC all int types have the same size on 32 and 64 bit; i.e. long is also 32 bit.

The types int8_t, int16_t, ect... are what the fundamental types should have been in the first place.

I guess my point is; why does MSVC declare the data types prefixed with "__" a fixed size, yet \most\ other compilers determine the globally used "int"(etc.) as a fixed size? Is there any scenario that I should dread about a non-fixed size integer?

Yes, you should always assume that any size that isn't fixed might change in the future or from OS to OS or from compiler to compiler or from hardware to hardware. Unless you use a fixed size.

uint32_t, int32_t, uint64_t, etc... are standardized.

Edit: I am aware that 'int' on a x86 build is 32 bits, yet should be 64 bits on a x64 build.

Actually, we've decided that 'int' should now be a constant 32 bits, even on 64 bit systems, because some programmers () assumed it'd be a constant size, instead of using the fixed size ints that they were supposed to, and too much code would've broke in the transition.

Int wasn't supposed to be a fixed size, it was supposed to be the best size for that system - that system's native size. But too many people didn't get the memo.
If your code needs a variable to be a certain size, then enforce it in the code. Don't have the code assume it, make the code guarantee it.