2021-04-02 11:18 AM
For some reasons, stm32h7 has strange builtin definitions, defining some of the standard 32-bit integer quantities as "long" variables, see the attached grepping of my language.settings.txt file.
The problem with this relic of the 16-bit era of computing is that a simple file like:
#include <stdio.h>
#include <stdint.h>
int main()
{
int32_t n = 2+2;
int *p = &n;
printf("Hello World, 2+2 = %d\n", n);
}
Generate errors and warnings, unlike on any other platform. This means that when compiling large open source code, hundreds or thousands of errors and warning are needlessly generated.
Also note that in ma attached language.settings.txt file, there is no consistency between, say, __INT_FAST32_TYPE__ (int) and __INT_LEAST32_TYPE__ (long int).
I've tried to workaround that problem by undefining and redefining these macros in the IDE (see image below), but without success so far (on the compiler command line, the -U are weirdly put _after_ the -D, therefore this doesn't work).
Is there a clean way out of this mess?
It would be great if all the 32-bit quantities in <stdint.h> were defined simply as "int"!
Thanks!
2021-04-03 12:55 AM
That's a question of the gcc toolchain you are using in your project.
This all depends on the gcc built-in macro:
C:\ST\STM32CubeIDE\gcc-arm-none-eabi-10-2020-q4-major\bin\arm-none-eabi-gcc.exe -E -dM - < NUL | find "__INT32"
#define __INT32_MAX__ 0x7fffffffL
#define __INT32_C(c) c ## L
#define __INT32_TYPE__ long int
You may install a custom toolchain with a different behaviour. But, the one provided by ARM: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads does exactly the same.
So, I wouldn't call it a STM32CubeIDE bug, but a common arm-none-eabi-gcc behaviour.
Maybe you can reconfigure it to meet your needs.
An ISO C purist would use
printf("Hello World, 2+2 = " PRId32 "\n", n);
anyway, but who else is using that?
hth
KnarfB