Исходное сообщение
"Уязвимости в QoS-подсистеме ядра Linux, позволяющие поднять ..." Отправлено Аноним, 13-Апр-23 12:35
> Это ситуация, обратная успешному освобождению. См №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". Ибо нефиг.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, [email protected] (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
	Введите код, изображенный на картинке: