In WString.cpp some of the methods access the insecure version of strcmp and strcnmp

[gorlov-ai]

1.In brief: in the String class of the WString.cpp library, the following method responses access string comparison functions (strcmp() and strcnmp()) that are not ESP8266-safe:

• bool String::endsWith(const String &s2) const;
• bool String::equals(const char *cstr) const;
• int String::compareTo(const String &s) const;
• bool String::startsWith(const String &s2, unsigned int offset) const.

2.Problem description: because the listed methods use functions that cannot work with strings in external ROM, an exception (3) occurs when working with the specified methods for strings declared as F() or PSTR().

3.An example that will result in exception (3): if(someString.equals(PSTR("eqString")) {// todo something} >>> exception (3): in console log.

4.Solution: replace strcmp() with strcmp_P(), strcnmp() with strcnmp_P().

[mcspr]

Solution: replace strcmp() with strcmp_P(), strcnmp() with strcnmp_P().

...?
AI summary mixes up some things here, by not looking at the implementation and imagining things just few lines apart.

There is indeed an issue with <string> funcs when using other const char* overloads. Neither const String& nor const __FlashStringHelper* are actually affected. String buffer is never in flash, flash string helper is converted to String.

Arduino/cores/esp8266/WString.cpp

Lines 542 to 556 in 78d0d0a

	bool String::equals(const String &s2) const {
	return (len() == s2.len() && compareTo(s2) == 0);
	}
	bool String::equals(const char *cstr) const {
	if (len() == 0)
	return (cstr == NULL || *cstr == 0);
	if (cstr == NULL)
	return buffer()[0] == 0;
	return strcmp(buffer(), cstr) == 0;
	}
	bool String::equals(const __FlashStringHelper *s) const {
	return equals(String(s));
	}

(although... String technically could be in IRAM by using custom heap, but that a no-no already as it would crash on reads / writes anyway and require unaligned read / write exception handler installed)

[gorlov-ai]

It is clear that in most cases works with data in IRAM, but still the implementation with strcmp_P() will be safer in portable environments than the same strcmp(). I encountered this problem while trying to optimize system resources, so maybe someone else had similar problems.
In addition, in this class there are quite a lot of calls where aligned memory access is used, so for the general structure this place can also be brought into general order.

[mcspr]

Do you already have a patch ready, or do you mind that I edit it instead?

[gorlov-ai]

I guess I don't have a patch, because I just fixed it in my library. But if it's not a problem for you, you can do this fix yourself.