Compiler does not detect when the type of function pointers are different

[gilman88]

Describe the problem

This came to my attention from a contributor in this PR who was trying to fix compile errors for a RP2040 platform. I found that the compiler was ignoring differences in the return types (bool vs void) when assigning the function pointer to a variable, I did some more poking and found that it would also ignore differences in argument types both within the library code and in end user code. I also tried finding another library that I could replicate the issue using one of their examples and was able to change the return type, the function didn't have arguments to try changing but it did give an error if I added an argument

To reproduce

Example 1

• Setup the example code here
• Change the return type of the saveParamCallback method (bool/long long/etc)
• Compile the project

Example 2

• Setup the example code here
• Define an empty function void foo(void *blk_id, size_t idSize, byte *data, size_t dataSize) {}
• Add xmodem.setBlockLookupHandler(foo) to the setup function
• Change the return types and argument types of the foo function
• Compile the project

Expected behavior

The compiler should return an error about incompatible function pointer types

Arduino CLI version

arduino-cli Version: nightly-20230605 Commit: f3ee0a8 Date: 2023-06-05T01:36:01Z

Operating system

Linux

Operating system version

Arch Linux

Additional context

No response

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details

[per1234]

Hi @gilman88. Thanks for taking the time to submit a report. Arduino CLI is not a compiler and Arduino does not develop compilers. It only invokes the compilation commands that are generated according to the patterns in the platform of the board you have selected.

So reports of the compiler behaving other than you expect are off topic for this issue tracker. You can take that up with the developers of the compiler.

[gilman88]

Apologies @per1234 but there are quite a few issues with compiler in the title already so I thought it was the right place.
I wasn't seeing any other obvious place for arduino compiler stuff since I believe the arduino IDE uses this project to build projects. Would you be able to point me in the right direction?
Is this https://github.com/arduino/toolchain-avr where this work is done? However that doesn't really make sense since this should be the avr toolchain whereas I got the same behaviour from the WiFiManager example which uses an esp32 toolchain...
From the other side of the coin my system gcc compiler does not have a similar problem so it can't be coming from there.

[per1234]

If you add the --verbose flag to your arduino-cli compile command (or enable the "Verbose output during: > compile" preference if using Arduino IDE, you can see the path of the compiler that is being used in the output of the compilation. It will be different depending on which board you have selected (though it is generally a variant of GCC. You will also be able to see which version of the compiler is being used as well as the specific flags. If you run the same compilation commands directly then you should get the same result as when Arduino CLI or Arduino IDE runs the command for you.

[WestfW]

I do get a warning when I do the "example2" instructions in the Arduino IDE 1.8.13:

/Applications/Arduino-1.8.13.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++ -c -g -Os -Wall -Wextra -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I/Applications/Arduino-1.8.13.app/Contents/Java/portable/packages/arduino/hardware/avr/1.8.5/cores/arduino -I/Applications/Arduino-1.8.13.app/Contents/Java/portable/packages/arduino/hardware/avr/1.8.5/variants/standard -I/Applications/Arduino-1.8.13.app/Contents/Java/portable/sketchbook/libraries/XModem/src /tmp/Arduino1.8.13Build/sketch/Basic_Send.ino.cpp -o /tmp/Arduino1.8.13Build/sketch/Basic_Send.ino.cpp.o

   👍 

/var/folders/gv/zn3wcml52jq0vvjnd95j8g6h0000gp/T/arduino_modified_sketch_976381/Basic_Send.ino: In function 'void setup()':
/var/folders/gv/zn3wcml52jq0vvjnd95j8g6h0000gp/T/arduino_modified_sketch_976381/Basic_Send.ino:13:35: warning: invalid conversion from 'bool (*)(void*, size_t, byte*, size_t) {aka bool (*)(void*, unsigned int, unsigned char*, unsigned int)}' to 'void (*)(void*, size_t, byte*, size_t) {aka void (*)(void*, unsigned int, unsigned char*, unsigned int)}' [-fpermissive]
   xmodem.setBlockLookupHandler(foo);
                                   ^

Presumably it gets passed because of -fpermissive

[gilman88]

Ah thanks alot, this has cleared things up for me. From what I can understand this comes down to both the permissive flag being used along with the default warnings setting being "none" effectively squashing the errors and I can get them back by including a warnings flag to the compile command. I don't know enough about compilers and platform ABI's to know if this is entirely benign but it is definitely a gotcha for people trying to use different toolchains.

I understand that the arduino ecosystem is trying to be as frictionless as possible but I think the cli version of the tool shouldn't squash compiler warnings by default and it would be nice if there was a flag for the permissive setting although with all the existing libraries that could be a no-go.

Anyways now I want a way to override the warnings setting in my arduino-cli config which has already been suggested here #1085 so I'll add my voice there