[compiler Warnings]: Compile with `-Wconversion` and `-Wsign-conversion` brings up many Warnings

[hasenradball]

Dear Developer Team,

compiling Code with the options:

-Wconversion
-Wsign-conversion

brings up many warnings which should be handled from my point of view.

Maybee it is a good idea to enable this warnings during development.

-Wsign-conversion:

Warn for implicit conversions that may change the sign of an integer value, like assigning a signed integer expression to an unsigned integer variable. An explicit cast silences the warning. In C, this option is enabled also by -Wconversion.

-Wconversion

Warn for implicit conversions that may alter a value. This includes conversions between real and integer, like abs (x) when x is double; conversions between signed and unsigned, like unsigned ui = -1; and conversions to smaller types, like sqrtf (M_PI). Do not warn for explicit casts like abs ((int) x) and ui = (unsigned) -1, or if the value is not changed by the conversion like in abs (2.0). Warnings about conversions between signed and unsigned integers can be disabled by using -Wno-sign-conversion.

For C++, also warn for confusing overload resolution for user-defined conversions; and conversions that never use a type conversion operator: conversions to void, the same type, a base class or a reference to them. Warnings about conversions between signed and unsigned integers are disabled by default in C++ unless -Wsign-conversion is explicitly enabled.

Warnings about conversion from arithmetic on a small type back to that type are only given with -Warith-conversion.

[earlephilhower]

That ship has sailed for this repo, as they say. There's not active work here anymore. While I understand that deployed devices will continue using the 8266, anything new in the last few years really has no reason not to use any of the numerous ESP32 chips instead with massively more power and RAM.

If the warnings bother you, feel free to submit a PR with fixes, but I think it's not really worth your or anyone's time in 2026...

[hasenradball]

Dear @earlephilhower i tried to switch from ESP-01 and ESP8266 to ESP32-C3 for example but!

The ESP32 brother may have more RAM
but less wifi range. And some chips are too big for the work thy have to do.

I use an ESP-01 in the freezer of my garage ... no problem with the ESP12 F or the ESP-01, but the ESP32 will not reach the wifi in the house.

So what do I need the same minmum wifi signal strength and range first.

Tell me what can an ESP-C3 do what an 8266 can no?

[earlephilhower]

Well, off the top of my head it can't do AAC SBR decode because the 8266 doesn't have enough RAM. And streaming HTTPS MP3 and AAC simple profile, not enough CPU. I keep a couple audio libraries so have first hand experience. :)

Anyway, more power to you if you want to stick with the 8266. But the existing core seems to work well enough even with those warnings. Some may be real problems, of course, but there are other issues probably more important.

Feel free to start thru the code and begin fixing them, but unless you are having a specific issue, I don't think it's a worthwhile use of your time.

[hasenradball]

I got your point 😊

Hope the developers will switch on the conversion warnings ob ESP32.

Which ESP32 is your favorite module?

[earlephilhower]

Easy question! The https://github.com/earlephilhower/arduino-pico of course. 😆

But other than the obtuse closed source SDK that seems to change every release, the modern ESP chips are all pretty neat. The issue for me is that there are just too many to keep track of, and each had its quirks, and the documentation for the SDK bits I have had to use was not very good. Their Arduino core seems nice, too, if a little limited on the I2S front.