Короткий ответ — поведение не определено $UB$. Объяснение и рекомендации ниже.

Что происходит в примере

Вы берёте const char* p = s.c_str; — это указатель на внутренний буфер std::string, содержащий нуль-терминированную C-строку.Затем вы вызываете s += "x"; — это немодифицирующее $non-const$ действие, которое меняет содержимое/длину строки и может привести к $ре$аллоцированию внутреннего буфера.Если при добавлении произошла реаллокация, p станет «висячим» $dangling$ — указатель будет указывать на освобождённую/неверную память. Чтение через такой указатель — UB. Даже если реаллокации не произошло, зависеть от этого нельзя — поведение не гарантировано стандартом.

Что гарантирует стандарт

std::string::c_str возвращает указатель на нуль-терминированный массив символов, соответствующий строке.Начиная с C++11, элементы std::string хранятся в непрерывной области памяти $contiguousstorage$.Указатели, ссылки и итераторы, указывающие на элементы строки, остаются действительными до первой немодифицирующей операции, которая изменяет строку $изменяющейдлину$ или до уничтожения объекта. Другими словами: любые неконстантные операции, изменяющие строку $включая+=,append,eraseит.п.$, могут инвалидировать внутренние указатели/итераторы/ссылки.Никаких гарантий о «неперераспределении» памяти при модификации строки стандарт не даёт — конкретно: реаллокация может произойти и тогда указатель станет недействительным.

Опасности использования указателей на внутреннюю память

Висячие указатели → чтение/запись освобождённой памяти → крах, коррупция данных, уязвимости безопасности.Код может «работать» на одной реализации или с определённой вместимостью $capacity$, но ломаться на другой платформе, в другом билде или при других входных данных.std::string_view также лишь ссылается на данные; он не продлевает их время жизни и подвержен тем же проблемам, если исходная строка изменится/удалится.

Безопасные альтернативы и практики
1) Не держите указатель на внутреннюю память через модификации строки:

Берите p = s.c_str только непосредственно перед использованием и не модифицируйте s до использования p:
const char* p = s.c_str;
printf("%s\n", p); // OK

2) Копируйте, если нужен отдельный буфер:

std::string copy = s; const char* p = copy.c_str; — копия живёт независимо.Или явно выделите буфер $std::vector<char>илиnewchar[]$, скопируйте данные и используйте его.

3) Используйте std::string_view корректно:

string_view не владеет данными, поэтому пригоден только если вы гарантируете, что исходный std::string $илидругойбуфер$ остаётся неизменным и живёт дольше view.

4) Если хотите избежать реаллокаций, заранее зарезервируйте вместимость:

s.reserve$нужны{й}_{c}apacity$;Тогда некоторые последующие append/+= не будут реализовывать перераспределение и указатель останется валидным. Но это хрупкое решение — легко ошибиться, забыть reserve, изменить код и получить UB. Использовать только если контролируете всё изменение строки.

5) Предпочитайте безопасные API:

printf("%s\n", s.c_str()) — безопасно.Лучше — использовать std::puts$s.c_{s}tr()$ или std::cout << s << '\n'; они не требуют хранения указателя извне.

Примеры правильного исправления

Если нужно вывести строку после изменения:
s += "x";
printf("%s\n", s.c_str()); // корректно

Если нужен стабильный C-строковый указатель, которому можно изменять исходник:
std::string stable = s;
const char* p = stable.c_str; // safe — stable не изменяем далее

Итог

Хранить const char* на внутренний буфер std::string через модификации этой же строки — неправильная практика, т.к. модификация может инвалидировать указатель и привести к UB.Используйте либо доступ к c_str непосредственно перед использованием, либо делайте копию, либо применяйте другие безопасные структуры/подходы $reserve—тольковконтролируемыхслучаях$.