В Си, почему некоторые люди приводят указатель перед освобождением?

Я работаю над старой базой кода и почти каждый вызов free () использует приведение своего аргумента. Например,

free((float *)velocity);
free((float *)acceleration);
free((char *)label);

где каждый указатель имеет соответствующий (и соответствующий) тип. Я не вижу смысла делать это вообще. Это очень старый код, поэтому мне остается только подумать, что это за K & R. Если это так, я действительно хочу поддерживать старые компиляторы, которые, возможно, требовали этого, поэтому я не хочу их удалять.

Есть ли техническая причина использовать эти приведения? Я даже не вижу прагматичной причины использовать их. Какой смысл напоминать себе о типе данных прямо перед его освобождением?

РЕДАКТИРОВАТЬ: Этот вопрос не является дубликатом другого вопроса. Другой вопрос является частным случаем этого вопроса, который, я думаю, очевиден, если близкие избиратели прочитают все ответы.

Колофон: Я ставлю галочку "const answer", потому что это реальная причина, почему это может быть необходимо сделать; тем не менее, ответ о том, что это был пре-ANSI C обычай (по крайней мере, среди некоторых программистов), кажется, является причиной его использования в моем случае. Много хороших моментов многими людьми здесь. Спасибо за ваш вклад.

Приведение может потребоваться для разрешения предупреждений компилятора, если указатели есть const. Вот пример кода, который вызывает предупреждение без приведения аргумента free:

const float* velocity = malloc(2*sizeof(float));
free(velocity);

И компилятор (gcc 4.8.3) говорит:

main.c: In function ‘main’:
main.c:9:5: warning: passing argument 1 of ‘free’ discards ‘const’ qualifier from pointer target type [enabled by default]
     free(velocity);
     ^
In file included from main.c:2:0:
/usr/include/stdlib.h:482:13: note: expected ‘void *’ but argument is of type ‘const float *’
 extern void free (void *__ptr) __THROW;

Если вы используете free((float*) velocity);компилятор, перестает жаловаться.

У предстандарта C не было ничего, void*кроме char*, так что вы должны были привести все переданные параметры Если вы столкнетесь с древним кодом C, вы можете найти такие приведения.

Подобный вопрос со ссылками .

Когда первый стандарт C был выпущен, прототипы таНос и бесплатно изменилось от того , char*на void*что у них еще есть сегодня.

И, конечно, в стандарте C такие броски излишни и просто вредят читабельности.

Вот пример, где free потерпит неудачу без приведения:

volatile int* p = (volatile int*)malloc(5 * sizeof(int));
free(p);        // fail: warning C4090: 'function' : different 'volatile' qualifiers
free((int*)p);  // success :)
free((void*)p); // success :)

В C вы можете получить предупреждение (есть в VS2012). В C ++ вы получите ошибку.

За исключением редких случаев, кастинг просто раздувает код ...

Изменить: я бросил, чтобы void*не int*показывать сбой. Он будет работать так же, как int*будет преобразован в void*неявно. Добавлен int*код.

Старая причина: 1. При использовании в free((sometype*) ptr)коде явно указывается тип, указатель должен рассматриваться как часть free()вызова. Явное приведение полезно, когда free()его заменяют на (сделай сам) DIY_free().

#define free(ptr) DIY_free(ptr, sizeof (*ptr))

DIY_free()Был (есть) способ, особенно в режиме отладки, чтобы сделать во время выполнения анализа указателя освобождения. Это часто сочетается с DIY_malloc()добавлением предложений, подсчета общего использования памяти и т. Д. Моя группа использовала эту технику в течение многих лет, прежде чем появились более современные инструменты. Он обязал, чтобы предмет, являющийся свободным, был приведен к типу, который был первоначально выделен.

2. Учитывая много часов, потраченных на отслеживание проблем с памятью и т. Д., Маленькие хитрости, такие как приведение типа free'd, помогут в поиске и сужении отладки.

Современный: избегать constи volatileпредупреждать в соответствии с указаниями Manos Nikolaidis @ и @egur . Думал , что я хотел бы отметить эффекты 3 классификаторов : const, volatile, и restrict.

[править] Добавлено char * restrict *rp2за @R .. комментарий

void free_test(const char *cp, volatile char *vp, char * restrict rp, 
    char * restrict *rp2) {
  free(cp);  // warning
  free(vp);  // warning
  free(rp);  // OK
  free(rp2);  // warning
}

int main(void) {
  free_test(0,0,0,0);
  return 0;
}

Вот еще одна альтернативная гипотеза.

Нам говорят, что программа была написана до C89, что означает, что она не может обойти какое-то несоответствие с прототипом free, потому что не только не было такой вещи, как constи void *до C89, не было такой вещи, как прототип функции до C89. stdlib.hСам был выдумкой комитета. Если бы системные заголовки не удосужились объявить freeвообще, они бы сделали это так:

extern free();  /* no `void` return type either! */

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

Тем не менее, это еще не означает, что необходимо было приводить аргументы в freeбольшинстве компиляторов K & R. Функция как

free_stuff(a, b, c)
    float *a;
    char *b;
    int *c;
{
    free(a);
    free(b);
    free(c);
}

должен был быть правильно скомпилирован. Поэтому я думаю, что у нас есть программа, написанная для работы с ошибочным компилятором для необычной среды: например, для среды, где sizeof(float *) > sizeof(int)компилятор не будет использовать соответствующее соглашение о вызовах для указателей, если вы их в точку вызова.

Я не знаю ни о какой такой среде, но это не значит, что ее не было. Наиболее вероятные кандидаты, которые приходят на ум, - это урезанные «крошечные C» компиляторы для 8- и 16-битных микро в начале 1980-х. Я также не удивлюсь, узнав, что у ранних Crays были такие проблемы.

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

Невозможно освободить константные указатели в C