Description
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();
}
#endifDebug 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)