The official name would have been uint16_t and uint32_t. A lot of coders would try to save keyboard wear by using u16 and u32 instead.

Another thing is that the language standard has datatypes uint_least16_t and uint_fast16_t. Not meaningful if a block of code will never ever be moved to a different processor, but history has shown that we really don't know what happens next year or maybe five years from now.

With good use of data types, it will be possibe to take quite big code blocks from a 32-bit or 64-bit host machine and move to an 8-bit processor. Or it will be possible to take code from an 8-bit processor and compile and run on a 16-bit, 32-bit or 64-bit processor.

I often create wrappers to allow a PC (Linux or Windoze) machine to compile different parts of an embedded application and to run through large amounts of pre-generated input data. The huge bandwidth to different I/O on the PC can allow huge amounts of regression data to be processed, and refined into a short list of tests that did not produce the expected results.

The PC can't do systems tests, and it can't test the peripherials, but it is great for performing black-box module tests of a quite large percentage of the code in the embedded applications I develop. The only thing I can't really simulate on the PC is code built with integer promotion turned off since integer promotion isn't normally something a compiler should be able to turn off. That means that it is extra important that code affected by integer promotion must be very explicit with type casts.