Коротко: чтение через указатель на уже освобождённую память — неопределённое поведение (use‑after‑free). В вашем фрагменте — $\text{int *p = malloc(sizeof(int)*n);}\text{free}(p);\text{printf}("$ — выражение $p[0]$ эквивалентно $\ast (p+0)$, то есть это разыменование висячего указателя.
Почему это UB:
- После $\text{free}(p)$ блок памяти возвращён в кучу; содержимое может быть сразу перезаписано или метки структуры аллокатора изменятся. Указатель $p$ при этом не обнуляется автоматически — он становится висячим (dangling).
- Стандарт C говорит, что разыменовывать указатель на освобождённую память нельзя — поведение не определено. Компилятор может оптимизировать код, предполагая, что такого не происходит, что приведёт к неожиданным преобразованиям/удалению кода.
Возможные реальные последствия:
- немедленный краш (segmentation fault) при доступе;
- чтение «старых» значений или мусора — неверные результаты;
- последующие malloc/free могут привести к повреждению кучи и поздним крашам или неверному поведению;
- уязвимости безопасности (эксплуатация use‑after‑free);
- оптимизатор компилятора может удалить или изменить код, делая поведение непредсказуемым.
Как правильно управлять освобождением:
- Никогда не разыменовывайте память после $\text{free}$.
- Обнуляйте указатель после освобождения: $\text{free}(p);p=\text{NULL};$ — это предотвращает случайное дальнейшее разыменование и делает проверку простой ($if(p)\dots$).
- Если есть несколько алиасов одного блока, гарантируйте, что все они больше не используются (обнуляйте или применяйте структуру владения).
- Не освобождайте память дважды ($\text{free}(p);\text{free}(p);$ — тоже UB).
- В многопоточном коде синхронизируйте доступ и освобождение (чтобы другой поток не взял указатель в использование после free).
- Для отладки используйте инструменты: Valgrind, AddressSanitizer ($-fsanitize=address$) — они найдут use‑after‑free и двойное освобождение.
Пример правильной практики:
int *p = malloc(\text{sizeof(int)} * n);
/* ...используем p... */
free(p);
p = NULL; // теперь дальнейшие обращения безопасно проверять через if (p)

Это кратко объясняет причину, последствия и корректные приёмы предотвращения use‑after‑free.