Different kind of symbol

[Archibald]

When I compile this code within the Arduino IDE . . . .

Code: Select all

float gamma;

void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:

}

. . . . I get the warning message "float gamma redeclared as different kind of symbol".

I don't get the warning if I compile for a Leonardo.

Is "gamma" a reserved word for the ESP32 or Is this a bug?

[ESP_krzychb]

Hi Archibald,

Indeed there is 'gamma' already declared in arduino-esp32, see https://github.com/espressif/arduino-es ... ath.h#L297

[Archibald]

Many thanks.

So there is quite a large number of extra 'reserved words' when compiling for an ESP32. I was expecting only the usual C++ reserved words and the Arduino extras such as "delay".

[ESP_Sprite]

Gamma would be a reserved word anywhere with a C library like Newlib or glibc and with math.h included: it's a fairly standard Unix-y math function.

[Archibald]

Thanks Sprite,

I was expecting anything that compiles for an Arduino should compile for the ESP32. I still think that should be the case (unless impossible due to hardware differences).

According to Wikipedia (here) in a standard library for C it should be tgamma, not gamma.

[ESP_Angus]

I was expecting anything that compiles for an Arduino should compile for the ESP32. I still think that should be the case (unless impossible due to hardware differences).

This is a reasonable expectation, but behind the scenes AVR Arduinos are using avrlibc and ESP32 is using newlib. So there will be some small differences, mostly things which are missing from the much more resource constrained AVRs. We can't easily remove these things, because we implement a superset of the AVR-based Arduino chips' functionality (for things like WiFi and RTOS interactions, among others.)

According to Wikipedia (here) in a standard library for C it should be tgamma, not gamma.

The man page for gamma(3) on Linux helpfully tells us:

CONFORMING TO
Because of historical variations in behavior across systems, this function is not specified in any recent standard. It was documented in SVID 2.

SVID is the System V Interface Definiton. So we can blame the original Unix for this behaviour!

[Archibald]

Thanks for the information Angus.

I suggest we now treat this issue as closed.