> Это ситуация, обратная успешному освобождению. См №67, на которое я отвечал.

В вон том определении реализации функции просто нет места "call fails" - либо всегда success, либо UB. Если что, UB != call fails.

> deallocated by a call to free or realloc, the behavior is undefined.

Ну и как видите в этом (да, достаточно дурацком) определении не предусмотренно именно "fails". Вместо этого "хз что будет, ваша проблема". И вообще-то это пример того как апи делать не надо. Но в сях у комитета есть мерзкая привычка спихивать свои проблемы на других, чтобы не прописывать конкретику behavir. На мой вкус тут вопрос скорее к стандарту и апи самому по себе. Уж как минимум обязать free вешать null на указатель и чекать при входе в него что дали null и репортить жесткий usage error, вплоть до краха программы, было бы весьма логично (и не так уж дорого по ресурсам). Ядерщики кстати могли бы себе нечто такое и сделать - они стандартами си и тем более фичами libc не зажаты так то и у них много забавного кастома есть.

> И что возвращать в этом случае?

По уму это апи надо переделать, но мы повесимся из за слома совместимости.

> Если NULL, тогда можно самому занулять указатель, как и предалали.
> Если не NULL, тогда рац.предожение теряет смысл. Потому и не вижу ничего
> удивительно в текущей реализации.

Мне вообще вот это апи не особо нравится. Я бы вообще запретил комитетчикам использовать слово "undefined behavior". Ибо нефиг.