Esp32c3 `int32_t` should be `int` and not `long int`

[s-hadinger]

Hardware:

Board: Esp32c2 dev board Core Installation version: v.2.0.0.pre IDE name: Platform IO Flash Frequency: 40Mhz PSRAM enabled: no Upload Speed: 115200 Computer OS: Mac OSX

Description:

When using ESP32 or ESP8266, uint32_t matches unsigned int and int32_t matches int.

But with RISC-V compiler the uint32_t now matches unsigned long int and int32_t matches long int.

This causes compilation failure of multiple Arduino libs, specifically in Tasmota.

A workaround is to add -D__INT32_TYPE__=int -D__UINT32_TYPE__="unsigned int" in the build_flags but it creates lots of warnings.

The core issue is that gcc builtins for __INT32_TYPE__ is long int and __UINT32_TYPE__ is unsigned long int.

I suggest to change the builtins in gcc.

Sketch:

#include <cstdint>

void test(int *a) {
  // do nothing
}

void setup() {
  int32_t i;
  test(&i);
}

void loop() {
}

Debug Messages:

The sketch does nothing but verify compilation. Esp32/Esp8266 compile fine.

Esp32c3 causes the following error:

Compiling .pio/build/tasmota32c3/src/main.o
src/main.cpp: In function 'void setup()':
src/main.cpp:10:8: error: invalid conversion from 'int32_t*' {aka 'long int*'} to 'int*' [-fpermissive]
   test(&i);
        ^~
src/main.cpp:4:16: note:   initializing argument 1 of 'void test(int*)'
 void test(int *a) {
           ~~~~~^
*** [.pio/build/tasmota32c3/src/main.o] Error 1

[lbernstone]

It is a 32-bit cpu, so I would expect that as well. Alas, we have no control over that. Please report upstream at esp-idf.

[s-hadinger]

Thanks, will do. Do you want me to keep this issue open for reference until it's fixed upstream?

For reference: https://github.com/espressif/esp-idf/issues/6906

[stale[bot]]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.