IRtext.{h,cpp} strings are not in PROGMEM

[mcspr]

Version/revision of the library used

2.7.20

Describe the bug

Currently used definition const PROGMEM char* X = "...stuff..."; is a no-op and simply refers to the string literal pool loaded in the RAM, it should be explicitly declared as const char X[] PROGMEM = "...stuff..." in the .cpp if the idea is to store things both in the flash and bound to a single object file

IRremoteESP8266/src/IRtext.h

Lines 12 to 13 in 10706fc

	// Constant text to be shared across all object files.
	// This means there is only one copy of the character/string/text etc.

IRremoteESP8266/src/IRtext.cpp

Line 195 in 10706fc

const PROGMEM char *kAllProtocolNamesStr =

Although, extern const char X[]; in the header does not work with arrays as the size is not known at compilation time and const char* X can't be used instead b/c it is a different type. One alternative is redirecting through a functionk, e.g. const char* protocols() { return &kAllProotoclNamesStr[0]; }, but one needs to be aware that this is a PSTR and only pgm_... reads work.

To Reproduce / example code

Running on the current esp8266 Core

#include <Arduino.h>
#include <IRtext.h>

const char teststring[] PROGMEM = "test\x00test\x00test";

void setup() {
    Serial.begin(115200);
    Serial.printf("%p\n", kAllProtocolNamesStr);
    Serial.printf("%p\n", &teststring[0]);
}

void loop() {
}

Will print 0x3ffxxxxx instead of something in the 0x402xxxxx range of the teststring[] var, where the flash strings are usually stored with the esp8266

Using something like gdb will also show the location when the -g option is set in the build flags line
(gdb.exe can be found with the gcc.exe and the rest of the toolchain, platformio.ini env modified build_flags = -g)

$ xtensa-lx106-elf-gdb.exe .\.pio\build\test\firmware.elf
(gdb) p /a kAllProtocolNamesStr
$1 = 0x3ffe8817
(gdb) p /a teststring
$2 = {0x74, 0x65, 0x73, 0x74, 0x0, 0x74, 0x65, 0x73, 0x74, 0x0, 0x74, 0x65, 0x73, 0x74, 0x0}
(gdb) p /a &teststring[0]
$3 = 0x4027a6e5 <_ZL10teststring>
(gdb)

[crankyoldgit]

Xref #1493

[mcspr]

Although, extern const char X[]; in the header does not work with arrays as the size is not known at compilation time and const char* X can't be used instead b/c it is a different type

Correction, as noticed here:
https://chromium.googlesource.com/chromium/src/+/HEAD/url/url_constants.h

What turned out to be the issue is that the extern const char VAR[]; needs to be in both object files. e.g.

// a.cpp
extern const char arr[];
const char arr[] __attribute__((section("\".whatever\""))) = "hello world";

// b.cpp
#include <iostream>

extern const char arr[];

int main() {
    std::cout << arr << '\n';
}

$ g++ -c -o a.o a.cpp
$ g++ -c -o b.o b.cpp
$ g++ -o run a.o b.o
$ ./run
hello world
$ size -A run | grep whatever
.whatever                 12   4202512

sizeof(arr) still does not work though, as it is still basically a simple pointer; but, at least it is possible to lose the additional const char* const arrPtr { &arr[0] };

---

Still, there's the issue with using this as C string. I was trying out a bit more 'modernized' API intended to replace the usage of PSTR(...) / F(...), and try to make it very similar to std::string_view. Unlike those macros, it can be used in the global scope (in .cpp only though, not in .h b/c section would be broken on esp32 as-is, or at least the last time I tried building). Small proxy / view struct also means it is pretty easy to have helper methods using ..._P funcs that work with the object directly and allowing to be very similar to the String API:

#include <Arduino.h>

// adjust accordingly (private members, const-only accessors, startsWith, substring, operator String(), etc.)
struct ConstStringPtr {
    const char* ptr;
    size_t len;

    template <size_t Size>
    explicit ConstStringPtr(const char (&buffer)[Size]) :
        ptr(&buffer[0]),
        len(Size - 1)
    {}
};

static_assert(alignof(ConstStringPtr) == alignof(char*), "");

// aligned() is a must, otherwise it is 1
#define MY_PGM_STRING(VALUE)\
    ([]() {\
        static const char __pstr__[] __attribute__((aligned(4))) PROGMEM = (VALUE);\
        return ConstStringPtr{__pstr__};\
    })()

const auto A = MY_PGM_STRING("aaaaaaa");
const auto B = MY_PGM_STRING("bbbbbbb");
const auto C = MY_PGM_STRING("ccccccc");

void loop() {
}

void setup() {
    Serial.begin(115200);
    Serial.printf("%.*s (%p, %u), %.*s (%p, %u), %.*s (%p, %u)\n",
        A.len, A.ptr, A.ptr, A.len,
        B.len, B.ptr, B.ptr, B.len,
        C.len, C.ptr, C.ptr, C.len);
    // %s still works, but now length is known even without the strlen_P
}

[crankyoldgit]

FYI, the changes mentioned above have now been included in the new v2.8.0 release of the library.