> Just like there is no standard for sizeof(int) or whatever, because it started with one size on one CPU and somebody brought it to a different CPU where another size made better sense. Today you can usually guess that it's 32 bits, but there are domains where it's not.
This is different: C has to be implemented efficiently on a wide range of hardware, almost without regard for how good of a fit that hardware is for C or any modern language. Machines with 36-bit integers and 18-bit pointers? They got C compilers. Machines with no native notion of byte addressability? Plenty of C compilers for those things. Machines with application-visible segmentation? Of course! Those machines were quite popular for a while.
Therefore, the C programming language has to at least try to make it possible for portable programs to exist. That's the implied contract of the C standard: Code to the standard, and your programs will be compilable and runnable on every platform targeted by a conformant C compiler. So, since int is going to be a size adapted to the hardware, as required for efficiency, the programs have to know how big an int is, as required for portability.
> Having the standard specify that every build needs to potentially pull down a bunch of crap from github or wherever else is going to be really annoying to a lot of people.
No language standard specifies that, I'm pretty sure. The ES6 standard doesn't specify left_pad and the C++ standard doesn't specify Boost. However, the standards also don't specify things which could replace those external libraries in a portable fashion which is guaranteed to always be there. If you take something out of the standard library, it has to go somewhere; people aren't going to stop doing that thing just because the standard no longer mentions it.