Universally available, but not universally efficient. The point of the flexible-width types is that the same code can compile on different platforms with different sizes and work to the spec that the platform is designed for without being unnecessary inefficient. For generic libraries, I'd assume this is quite important. For platform specific code you know the sizes of the types anyway, so the difference is just about semantics at that point l.

You can certainly demand a certain width of a type, but it is something I do sparingly - for example, a nanosecond precision Unix timestamp has minimum width in my code because overflow in the foreseeable future would be catastrophic, but with many other things it makes sense to stick to defaults. It's the choice of the developer. Use the platform dependant types or use the fixed width types - just be aware of the differences and the use cases of each and all will be golden.

There's far too much talk about "most of the time", "normally", etc in this thread and anything that follows is, I believe, anecdotal. I have no idea what behaviours that the microcontrollers on robot arms, or in a self driving car, in a plane, or on board a satellite have, and I have no idea what kind of problems the developers using such platforms face. People with such experience are better placed to make comments about how sensible default types are than I.

Going back to the original topic, though, I'm strongly against a communication format being used to dictate types being used by processing  that's the tail wagging the dog. Communication formats that I work with, for example, are often packed structs which need converting into efficient-to-process layout anyway - unless you're barely doing any processing with the data, the performance benefits from a receive-filter-convert-process pipeline rather than a receive-process pipeline are significant, and on many platforms the former is mandatory. The same goes for the primitives within the struct - if a target platform handles things in its own way, it might have a good reason for it.

On Wed, 16 Oct 2019, 08:26 Andrey Semashev via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
On 2019-10-16 10:20, Thiago Macieira via Std-Proposals wrote:
> On Wednesday, 16 October 2019 00:17:28 PDT Andrey Semashev via Std-Proposals
> wrote:
>> (u)int_leastN_t types are good for guaranteeing the lowest size, but
>> they don't they don't offer much compared to (u)intN_t. Given that
>> (u)intN_t are universally available, people don't see the point in using
>> them.
> According to the standard (u)intN_t aren't universally required, but
> uint_leastN_t are.

Yes, but in practice they are universally available. As are (u)intptr_t.
Std-Proposals mailing list