Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: ESP-12
• Core Version:612e7ff
• Development Env: PlatformIO
• Operating System: Windows

Settings in IDE

Defaults

Problem Description

Using std::begin and std::end or the equivalent &buf[0] and &buf[Size], sometimes the resulting string pointer happens to be at a different location than expected. Using addresses(std::begin(...), std::end(...)); outside of the template produces the same results. Referring to &buf[Size-1] aka '\0' does not result in the incorrect pointers though.

Originally noted in the earlephilhower/newlib-xtensa#19 (comment), but it might be something different than string suffix merging / anything related to the toolchain or libc? (and not to continue an already long issue thread. plus, I hope I have not broken toolchain installation somehow)

MCVE Sketch

#ifdef NATIVE #include <cstdint> #include <cstdio> #include <iterator> #else #include <Arduino.h> #endif void addresses(const char* const begin, const char* const end) { ::printf("%p:%p -> (%u)\n", begin, end, end - begin); } template <size_t Size> void addresses(const char (&buf)[Size]) { addresses(std::begin(buf), std::end(buf)); } void test() { addresses(""); addresses(","); } #ifndef NATIVE void setup() { Serial.begin(115200); delay(1000); ::puts("\n\n\n"); test(); } void loop() { delay(100); } #else int main() { ::puts("\n\n\n"); test(); } #endif

Debug Messages

0x3ffe87e0:0x3ffe87e1 -> (1) 0x3ffe87e1:0x3ffe87dd -> (4294967292) 

Which is not the expected result. Inspecting the binary, "," is actually at the 0x3ffe87db as one would expect from the end (one past the last element of array of 2 elems)