Compilation error: v3.0.1 when used as esp-idf component

[ricardoquesada]

Board

sparkfun esp32 thing

Device Description

sparkfun esp32 thing

Hardware Configuration

N/A

Version

v3.0.1

IDE Name

idf-idf.py command line

Operating System

Linux

Flash frequency

40Mhz

PSRAM enabled

yes

Upload speed

115200

Description

compilation error when using Arduino Core v3.0.1 + ESP-IDF 5.1.4.
Arduino Core is used as component.

I just run "idf.py build" and fails to compile both in:

• components/arduino/cores/esp32/esp32-hal-adc.c
• components/arduino/cores/esp32/MacAddress.cpp

It used to compile Ok using Arduino Core v2.0.17 + ESP-IDF 4.4.7

Sketch

Not applicable.

Debug Message

* esp32-hal-adc.c


/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/esp32-hal-adc.c: In function 'analogContinuous':
/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/esp32-hal-adc.c:478:27: error: 'adc_unit' may be used uninitialized [-Werror=maybe-uninitialized]
  478 |   if (adc_handle[adc_unit].adc_oneshot_handle != NULL) {
      |       ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/esp32-hal-adc.c:461:14: note: 'adc_unit' declared here
  461 |   adc_unit_t adc_unit;
      |              ^~~~~~~~
cc1: some warnings being treated as errors
ninja: build stopped: subcommand failed.

• MacAddress.cpp

/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/MacAddress.cpp: In member function 'bool MacAddress::fromString6(const char*)':
/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/MacAddress.cpp:75:10: error: 'char* strncpy(char*, const char*, size_t)' specified bound 18 equals destination size [-Werror=stringop-truncation]
   75 |   strncpy(cs, buf, sizeof(cs));  //strtok modifies the buffer: copy to working buffer.
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~
/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/MacAddress.cpp: In member function 'bool MacAddress::fromString8(const char*)':
/home/riq/progs/esp-idf-arduino-bluepad32-template/components/arduino/cores/esp32/MacAddress.cpp:94:10: error: 'char* strncpy(char*, const char*, size_t)' specified bound 24 equals destination size [-Werror=stringop-truncation]
   94 |   strncpy(cs, buf, sizeof(cs));  //strtok modifies the buffer: copy to working buffer.
      |   ~~~~~~~^~~~~~~~~~~~~~~~~~~~~
cc1plus: some warnings being treated as errors

### Other Steps to Reproduce

_No response_

### I have checked existing issues, online documentation and the Troubleshooting Guide

- [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

Thanks for reporting it!

[me-no-dev]

@ricardoquesada are you sure you did not change any settings? The core is compiled with IDF constantly and we do not get those errors

[ricardoquesada]

sorry, my bad... yes, I'm using:

CONFIG_COMPILER_OPTIMIZATION_PERF=y

in sdkconfig.defaults

[Jason2866]

Duplicate of #9607

[VojtechBartoska]

Thanks for pointing that out @Jason2866. Please take a look @lucasssvaz

[ricardoquesada]

Technically this is not a duplicate of issue #9607

Issue #9607 mentions a bug in RainMaker.

This issue is about bugs in Arduino Core: esp32-hal-adc.c and MacAddress.cpp files.

[Jason2866]

Technically it is the same, the reason is [-Werror=stringop-truncation]
Just happening in different code parts.

[ricardoquesada]

The root cause is that when using CONFIG_COMPILER_OPTIMIZATION_PERF=y is triggering different bugs:

• RainMaker: [-Werror=stringop-truncation]
• Arduino Core:
  • MacAddress.cpp: [-Werror=stringop-truncation]
  • esp32-hal-adc.c: [-Werror=maybe-uninitialized]

[SuGlider]

The root cause is that when using CONFIG_COMPILER_OPTIMIZATION_PERF=y is triggering different bugs:

• RainMaker: [-Werror=stringop-truncation]

• Arduino Core:

  • MacAddress.cpp: [-Werror=stringop-truncation]
  • esp32-hal-adc.c: [-Werror=maybe-uninitialized]

@lucasssvaz
Please take alook into the warnings that @ricardoquesada has pointed out.
We may just need to change a few parts the code in order to avoid it.
I think that improving the code is always a good move.