uint32, int16, uint8 .. Why these commonly used data types are not making it into the standards [closed]

Question

Over the years across multiple orgs and various projects involving C/C++ I have seen the need for fixed-width integers has been addressed by defining a local version of types.h which would mostly look like this:-

typedef  signed char        int8;
typedef  unsigned char      uint8;
typedef  signed short       int16;
typedef  unsigned short     uint16;
typedef  signed long        int32;
typedef  unsigned long      uint32
typedef  signed long long   int64;
typedef  unsigned long long uint64;

Why are these not getting integrated into C/C++ standards?

I know C99 has standardized the likes of uint32_t. Similarly Microsoft has defined it's own UINT32 etc.. - But these still requires typedef s since usage of uintX lingo is widespread among legacy as well as new code written by seasoned developers

Am also aware of Boost Integer Library - Again that's not standard C++ as they clearly mention:-

Because these are boost headers, their names conform to boost header naming conventions rather than C++ Standard Library header naming conventions.

Thoughts on pros an cons of integrating [u]intX s into the official standards?

EDIT:
The question has generated quality answers and opinions already. Thanks they are informative and helpful!! Some comments suggest the question is not clear enough:-
"you're asking specifically about adding more aliases for the already-existing typedefs in the standard" - Yes precisely

@Pascal Cuoq's ans addresses the real issue in case these were to be added to the standards: -

Do not wait for the name uint32 to become the official name of an integer type in C++; it will probably never happen, precisely because so many programs are already typedef'ing a type to this name.

Answer 1

C99 introduced the header stdint.h (7.18), and C++11 imported it as <cstdint>.

You may be asking why the names of types in there are uint32_t instead of uint32. Simple: because then the names would clash with existing code.

POSIX had reserved the _t suffix for types. (You are not supposed to use _t for any type in your program, if you want to to be compatible with current and future POSIX systems. This is a common mistake that even experienced programmers make). POSIX had also used its reserved namespace to safely define type names in the uint32_t format.

C99 chose the same names as POSIX. From the point of view of the C committee, it was unlikely these names would break existing programs (backwards compatibility is a very important consideration when evolving the C language). Later, when they appeared in C++, there was more value in keeping compatibility between C++ and C than in choosing different names.

Do not wait for the name uint32 to become the official name of an integer type in C++; it will probably never happen, precisely because so many programs are already typedef'ing a type to this name.