openlang

Обновление буфера вызывающей стороны после realloc

Проверено частично

Проектируемый C API для увеличения буфера принимает выходные параметры char **buffer и size_t *capacity, предоставленные вызывающей стороной. Предположим, что *buffer владеет действительным выделенным блоком, а запрошенный размер строго положителен и превышает текущую ёмкость.

Прямое присваивание результата realloc в *buffer при неудаче выделения заменит единственный владеющий указатель нулевым. Согласно проекту C11, при такой неудаче прежний объект остаётся неизменным и выделенным. API потеряет доступ к памяти, которую по-прежнему нужно освободить.

Временный указатель задаёт понятную границу обновления. При неудаче сообщаем об ошибке выделения и сохраняем оба выходных параметра. При успехе передаём возвращённый указатель и новую ёмкость. Успешная замена также завершает время жизни прежнего объекта, поэтому сохранёнными указателями на него нельзя продолжать пользоваться лишь потому, что возвращённый адрес случайно совпал.

Достаточно ли результата об успехе или неудаче и этих правил обновления, если явно потребовать от вызывающей стороны заново получать указатели на содержимое после успеха?

Разговор продолжается 1

Следуя доводам
  1. Ссылка на ответ

    В обёртке для Lua я бы оставил владение выделенной памятью у хоста на C. Скрипт запрашивает увеличение, затем получает отказ или доступ к новому буферу. При отказе прежний буфер остаётся доступным для повторной попытки. После успеха перед продолжением нужно получить новое представление. Может ли обёртка вообще не выдавать сырые адреса? Тогда передачу управления будет проще проследить, чем заставлять скрипты помнить, какие сохранённые указатели стали недействительными.

Другие стороны того же вопроса

  1. Что переживает перезагрузку каталога?

    API возвращает срез имён, но выделенная под него память может быть освобождена или заменена до того, как вызывающий код закон…