WString: remove operator==(const __FlashStringHelper*)

[d-a-v]

fixes https://gitter.im/esp8266/Arduino?at=627fee0ed30b6b44ebeaa803

@bwjohns4 @JAndrassy there will still be a warning, because nullptr should be used instead of NULL.

[mcspr]

We don't want to overload comparisons though? Check out operator calls you are proposing with older versions, or the esp32 Core, or even the ArduinoCore API test suite.

// with 2.7.4
src/main.cpp: In function 'void setup()':
src/main.cpp:7:16: error: invalid conversion from 'int' to 'const char*' [-fpermissive]
     if (tmp == 5) {
                ^

Main ambiguity comes from fpstr vs. const char, that wasn't there in the older Core versions.
== NULL is still an equals(int), even with the overloaded nullptr you are adding
it is a warning, but not something critical from the gcc pov.

Yes, this is another case of older code breaking, but I'd rather WiFiManager fixes this issue b/c we add another heap of issues on top.

src/main.cpp: In function 'void setup()':
src/main.cpp:7:16: warning: passing NULL to non-pointer argument 1 of 'bool String::operator==(int) const' [-Wconversion-null]
    7 |     if (tmp == NULL) {
      |                ^~~~
In file included from /home/builder/.platformio/packages/framework-arduinoespressif8266@src-31d658a59f41540201fc3726a1394910/cores/esp8266/Arduino.h:291,
                 from src/main.cpp:1:
/home/builder/.platformio/packages/framework-arduinoespressif8266@src-31d658a59f41540201fc3726a1394910/cores/esp8266/WString.h:234:30: note:   declared here
  234 |         bool operator ==(int val) const {
      |

[d-a-v]

Removing ==(FlashStringHelper*) overload still allows comparison with P("test") which will use an implicit temporary String(P("test")),
and it also restores warning-less & correct comparison with NULL through ==(const char*) overload.

[mcspr]

note that #8106 used this as a way to shrink ESPeasy binary size due to a temporary String obj

[d-a-v]

note that #8106 used this as a way to shrink ESPeasy binary size due to a temporary String obj

True.
... after checking, the NULL comparison error is existing from this pull request, which happenned after few months 3.0.2 release.

[d-a-v]

With this last commit, NULL is correctly managed, with a deprecating warning so user is invited to switch to nullptr

[mcspr]

just note that the trade-off is someone will write obj == 5; returning false positive :)
(...and iirc ide default to 'no warnings', which does not help...)

[d-a-v]

Given that std::nullptr_t is a distinguishable type, I tried the same with decltype(NULL).
Despite the existence of the __null internal keyword and the __sentinel__ attribute, I currently cannot manage NULL separately from int/long.

I reverted: ==(FlashStringHelper*) is removed again.

We still have this:
#define NULL nullptr

[mcspr]

I think they refer to some old version of GCC (pre 4.6?) with the __null stuff.
And I'd like to find some examples of #define NULL std::nullptr, as it seems like something for the system header to have

[d-a-v]

The only one I could find that is installed on my workstation and probably rarely used(*).

(*)given std:: and using are both lacking

[mcspr]

So we could've had this
https://github.com/gcc-mirror/gcc/blob/1815462a6e53465c404f8a5f6116891492d4b50b/gcc/ginclude/stddef.h#L396

But, newlib overrides it
https://github.com/earlephilhower/newlib-xtensa/blob/ebc967552ce827f21fc579fd8c437037c1b472ab/newlib/libc/include/stdlib.h#L60-L62

edit: ...need to check the preprocessor chain, though, but I would guess it overrides it

[mcspr]

Also, glibc code requesting it
https://code.woboq.org/userspace/glibc/stdlib/stdlib.h.html#_M/__need_NULL

[d-a-v]

This change proposal ends up with simply removing operator==(FlashStringHelper).

[mcspr]

renamed
str == F(...) alternative would be str == PSTR(...) accepting progmem'ed strings
pointer coercion will drive us mad otherwise