Int_least64_t

[Basa Benejan]

Thisis a persistent problem in the C programming language, dating back to a horribly bad decision back in the early days, the fixing of which is on my list of things-to-do should I ever build a time machine.

As it stands, rather than using the C types short, int, long etc, use int32_t, int16_t, uint8_t for different signed and unsigned integers. Preprocessor directives convert these into the appropriate primitive types for whichever architecture you are compiling to.

The stdint types now part of the C standard go a long ways to help remove the width issues, but even today many if not most developers are still not using them.

Particularly the types that ensure a minimum width or the fastest type of a minimum size like:

int_least32_t int_fast16_t etc...

Too many people are still casually using int or unsigned int and we are starting to see that sloppiness cause issues in reverse. i.e. people write sloppy code in a 64 bit environment and it breaks when built for a 32 bit environment because the sizes of the default types are not large enough.

Look no further than the gnome 3 disk utility. It now breaks in 32 bit environments because there are many places where int or unsigned int were used instead of something like int_least64_t or uint_least64_t

As an example in Arduino land, a uint8_t maybe better/faster for a loop on AVR but not on other processors.

This is where something like uint_fast8_t should be used to allow the compiler to pick the type that is fastest.

The sloppiness in Arduino core code and type definitions makes it impossible to have portable sketch code across processors.

This is a great example why the stdint types were created and why the Arduino core code should be using them, but..... it doesn't.

3a8082e126