Кратко: функция
char* f(){ char buf[100]; strcpy(buf, "hello"); return buf; }
возвращает указатель на память локального массива buf, который живёт в стеке и уничтожается при выходе из функции — поэтому использование возвращённого указателя приводит к неопределённому поведению (UB): программа может работать «как будто правильно», выдавать мусор, падать или быть уязвимой для эксплуатации.

Почему это UB (пояснение):

Локальные переменные функции размещаются в стеке; при возврате из функции их область видимости и время жизни заканчиваются, память может быть перераспределена под другие фреймы. Указатель остаётся, но он указывает на память, срок жизни которой истёк — чтение/запись там = UB.Компилятор делает оптимизации, руководствуясь правилами языка, и может полагать, что такой указатель не будет использован; это усиливает непредсказуемость.

Стек vs куча (основные различия):

Стек: автоматическое выделение/освобождение, быстрый LIFO, ограниченный размер (обычно килобайты/мегабайты), локальные переменные, срок жизни — до возврата из функции.Куча (heap): явное/долговременное выделение через malloc/new и освобождение через free/delete, гибкий размер, управление временем жизни вручную, медленнее и склонна к фрагментации.
(Пример чисел: размер локального буфера в примере был (100).)

Как правильно организовать выделение и освобождение в C:

Вариант 1 — выделить в куче и требовать от вызывающего освободить:
char f(void){
char buf = malloc(strlen("hello") + (1));
if(!buf) return NULL;
strcpy(buf, "hello");
return buf;
}
// вызов:
char s = f();
if(s){ / использовать s */ free(s); }

или короче (POSIX):
char* f(void){ return strdup("hello"); } // освобождать free()

Вариант 2 — пусть вызывающий предоставляет буфер:
void f(char* out, size_t out_sz){
strncpy(out, "hello", out_sz);
out[out_sz- (1)] = '\0';
}

Вариант 3 — статическая область (непотокобезопасно, постоянная длина):
char* f(void){
static char buf[(100)];
strcpy(buf, "hello");
return buf;
}
// buf живёт всю программу, но данные будут общими между вызовами/потоками.

Чем грозит возврат указателя на стековую память:

Непредсказуемое поведение, трудноуловимые баги, возможные уязвимости безопасности (перезапись стека, утечка данных).Компилятор может удалить или изменить код, опираясь на UB, что делает отладку бессмысленной.

Сравнение поведения в C, C++ и Rust:

C: ручное управление памятью; возвращать указатель на локальную память — UB; правильно — выделять на куче или использовать буфер вызывающего.C++ (RAII): предпочтительно возвращать объекты с управлением времени жизни, например std::string — при возврате происходит перемещение/копирование, владелец и освобождение памяти управляются автоматически:
std::string f(){ return "hello"; } // безопасно
Также используют умные указатели (std::unique_ptr) для динамической памяти — освобождаются автоматически при выходе из области видимости (RAII).Rust: система владения и заимствований не позволит вернуть ссылку на локальную переменную (компилятор не скомпилирует). Правильно возвращать владение, например String или Box<T>:
fn f() -> String { String::from("hello") } // безопасно, передаёт владение

Итог: никогда не возвращайте указатель на локальную (стековую) память. В C используйте выделение в куче (и чётко документируйте, кто освобождает), или механизм, где вызывающий предоставляет буфер; в C++ и Rust предпочитайте автоматическое управление ресурсами (RAII/ownership), что исключает подобные ошибки.