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_at_[hidden]> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>