Определение поведения функции realloc () перед ее вызовом

Нет - и если подумать, это не сработает. Между тем, как вы проверяете, что он собирается делать, и фактически выполняя это, другой процесс может выделить память. В многопоточном приложении это не сработает. Между тем, как вы проверяете, что он собирается делать, и фактически выполняя это, другой поток может выделить память.

Если вас беспокоят подобные вещи, возможно, пришло время взглянуть на структуры данных, которые вы используете, чтобы увидеть, можете ли вы там решить проблему. В зависимости от того, как построены эти строки, вы можете сделать это довольно эффективно с помощью хорошо спроектированного буфера.

Я не думаю, что это возможно кроссплатформенным способом. Здесь - это код для реализации ulibc, который может дать вам подсказку, как это сделать в зависимости от платформы, на самом деле лучше найти исходный код glibc, но этот был поверх поиска Google :)

Поведение realloc(), вероятно, зависит от его конкретной реализации. И основывать свой код на этом было бы ужасным взломом, который, мягко говоря, нарушает инкапсуляцию.

Лучшее решение для вашего конкретного примера:

1. Найдите размер текущего буфера
   • Выделите новый буфер (с malloc()), больший, чем предыдущий
   • Скопируйте нужный префикс в новый буфер
   • Скопируйте строку из предыдущего буфера в новый буфер, начиная с префикса
   • Освободить предыдущий буфер

Если препятствия хорошо подходят для ваших потребностей в распределении памяти, вы можете использовать их функциональность быстрорастущий. Obstacks - это особенность glibc, но они также доступны в библиотеке свобода, которая довольно переносима.

Как отмечено в комментариях, случай 3 в вопросе (нет памяти) неверен; realloc() вернет NULL, если нет доступной памяти [вопрос решен].

Стив МакКоннелл в «Код завершен» указывает, что если вы сохраните возвращаемое значение из realloc() в единственной копии исходного указателя, когда realloc() не работает, вы просто потеряете память. То есть:

void *ptr = malloc(1024);
...
if ((ptr = realloc(ptr, 2048)) == 0)
{
    /* Oops - cannot free original memory allocation any more! */
}

Различные реализации realloc () будут вести себя по-разному. Единственная безопасная вещь, которую можно предположить, - это то, что данные будут перемещены в всегда - что вы всегда будете получать новый адрес при использовании realloc () памяти.

Как заметил кто-то другой, если вас это беспокоит, возможно, пришло время взглянуть на ваши алгоритмы.

Помогло бы хранение вашей строки в обратном направлении?

Иначе... просто malloc () больше места, чем вам нужно, и когда у вас закончится место, скопируйте в новый буфер. Простая техника - каждый раз удваивать пространство; это работает очень хорошо, потому что чем больше строка (т.е. чем больше времени потребуется на копирование в новый буфер), тем реже это потребуется.

Используя этот метод, вы также можете выровнять строку в буфере по правому краю, чтобы можно было легко добавлять символы в начало.

Почему бы не оставить пустое буферное пространство слева от строки, например:

char* buf = malloc(1024);
char* start = buf + 1024 - 3;
start[0]='t';
start[1]='o';
start[2]='\0';

Чтобы добавить «on» в начало вашей строки, чтобы сделать ее «на \ 0»:

start-=2;
if (start < buf) 
  DO_MEMORY_STUFF(start, buf);//time to reallocate!
start[0]='o';
start[1]='n';

Таким образом, вам не придется копировать буфер каждый раз, когда вы захотите выполнить вставку в начале.

Если вам нужно делать вставки как в начале, так и в конце, просто выделите немного места на обоих концах; вставки в середине, очевидно, все равно потребуют от вас перетасовки элементов.

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