I was writing a program the other day to run on an Arduino Nano which needed to keep track of a timer several hours into the future. I was using uint32_t variables when dealing with millisecond time math to be sure there was no chance of an overflow when dealing with longer time periods, but I still was hitting bugs involving overflow. I looked into the actual definition of the "uint32_t" type in the headers and discovered it is defined as "typedef unsigned int uint32_t attribute ((mode (SI)));" in "arduino/hardware/tools/avr/avr/include/stdint.h". I'm using Visual Studio Code with the Arduino-Makefile project, so I thought it might be showing me the wrong include file from the Arduino library, but I can't find any other definition of this type anywhere. According to the Arduino reference guide, the "int" datatype (and thus the "unsigned int" datatype) represents a 16-bit integer, not a 32-bit integer, so shouldn't "uint32_t" be defined as "unsigned long int"? In fact, in the same "stdint.h" file, int8_t, uint8_t, int16_t, and uint16_t are defined exactly the same as int32_t and uint32_t...I was under the impression that the entire point of the "exact-size" integer types was to be sure you get a variable of a certain width no matter the platform, as the types would be defined so as to yield the correct native data type for each platform.
I can actually see the correct type definitions of these types in stdint.h but they are inside an "#if defined(DOXYGEN)" guard, implying they're only defined correctly when documentation is being generated by Doxygen. That makes no sense to me. What am I missing?
EDIT: I was reading more on how the typedefs in "stdint.h" work, and see that the "attribute ((mode (SI)))" portion changes "int" on that line to mean an actual 32-bit int, but my "uint32_t" variable was definitely overflowing at exactly 65,536 until I changed it to be "uint64_t". I still feel like something's off somewhere, at least in my environment.