Em C, por que algumas pessoas lançam o ponteiro antes de liberá-lo?

Estou trabalhando em uma base de código antiga e praticamente toda chamada de free () usa uma conversão em seu argumento. Por exemplo,

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

onde cada ponteiro é do tipo correspondente (e correspondente). Não vejo sentido em fazer isso. É um código muito antigo, então fico me perguntando se é uma coisa de K&R. Nesse caso, desejo realmente oferecer suporte aos compiladores antigos que possam ter exigido isso, então não quero removê-los.

Existe uma razão técnica para usar esses modelos? Não vejo nem uma razão pragmática para usá-los. Qual é o sentido de nos lembrar do tipo de dados antes de liberá-lo?

Edição: Esta pergunta não é uma duplicata da outra pergunta. A outra pergunta é um caso especial desta pergunta, que eu acho óbvio se os eleitores próximos leiam todas as respostas.

Colophon: Estou dando a "resposta constante" a marca de seleção porque é uma verdadeira razão genuína pela qual isso pode precisar ser feito; no entanto, a resposta sobre ser um costume pré-ANSI C (pelo menos entre alguns programadores) parece ser o motivo pelo qual foi usada no meu caso. Muitos pontos positivos por muitas pessoas aqui. Obrigado por suas contribuições.

A conversão pode ser necessária para resolver os avisos do compilador, se os ponteiros estiverem const. Aqui está um exemplo de código que causa um aviso sem lançar o argumento free:

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

E o compilador (gcc 4.8.3) diz:

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;

Se você usar free((float*) velocity);o compilador para de reclamar.

O C pré-padrão não tinha void*mas apenas char*, então você tinha que converter todos os parâmetros passados. Se você encontrar o código C antigo, poderá encontrar esses elencos.

Pergunta semelhante com referências .

Quando o primeiro padrão C foi lançado, os protótipos para malloc e free mudaram de ter char*para o void*que eles ainda têm hoje.

E, é claro, no padrão C, esses modelos são supérfluos e prejudicam a legibilidade.

Aqui está um exemplo em que o free falharia sem um elenco:

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 :)

Em C, você pode receber um aviso (recebi um no VS2012). Em C ++, você receberá um erro.

Casos raros à parte, o elenco apenas incha o código ...

Edit: Eu lancei para void*não int*demonstrar a falha. Funcionará da mesma forma int*que será convertido void*implicitamente. int*Código adicionado .

Motivo antigo: 1. Ao usar free((sometype*) ptr), o código é explícito sobre o tipo que o ponteiro deve ser considerado como parte da free()chamada. A conversão explícita é útil quando free()é substituída por um (faça você mesmo) DIY_free().

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

A DIY_free()era (é) uma maneira, especialmente no modo de depuração, de fazer uma análise em tempo de execução do ponteiro sendo liberado. Isso geralmente é associado a um DIY_malloc()para adicionar sentenciais, contagens globais de uso de memória, etc. Meu grupo usou essa técnica por anos antes que ferramentas mais modernas fossem exibidas. Obrigava que o item que estava sendo liberado fosse lançado para o tipo que foi originalmente alocado.

2. Dadas as muitas horas gastas rastreando problemas de memória etc., pequenos truques como liberar o tipo free'd ajudariam a pesquisar e restringir a depuração.

Moderno: Evitar conste volatileavisos, conforme abordado por Manos Nikolaidis @ e @egur . Pensamento gostaria de observar os efeitos dos 3 eliminatórias : const, volatile, e restrict.

Adicionado char * restrict *rp2por @R .. comentário

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;
}

Aqui está outra hipótese alternativa.

Fomos informados de que o programa foi escrito antes da C89, o que significa que não pode haver algum tipo de incompatibilidade com o protótipo de free, porque não apenas não havia tal coisa constnem void *antes da C89, não havia tal coisa como um protótipo de função anterior a C89. stdlib.hem si foi uma invenção do comitê. Se os cabeçalhos do sistema se preocupassem em declarar free, eles teriam feito assim:

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

Agora, o ponto principal aqui é que a ausência de protótipos de função significava que o compilador não fazia verificação de tipo de argumento . Ele aplicou as promoções de argumentos padrão (as mesmas que ainda se aplicam a chamadas de funções variadas) e foi isso. A responsabilidade de alinhar os argumentos em cada local da chamada com as expectativas do receptor cabe inteiramente ao programador.

No entanto, isso ainda não significa que era necessário lançar o argumento freena maioria dos compiladores K&R. Uma função como

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

deveria ter sido compilado corretamente. Então, acho que o que temos aqui é um programa escrito para lidar com um compilador de buggy para um ambiente incomum: por exemplo, um ambiente em que sizeof(float *) > sizeof(int)o compilador não usaria a convenção de chamada apropriada para ponteiros, a menos que você os projete no momento da chamada.

Não conheço esse ambiente, mas isso não significa que não exista. Os candidatos mais prováveis ​​que vêm à mente são os compiladores "minúsculos C" reduzidos para micros de 8 e 16 bits no início dos anos 80. Também não ficaria surpreso ao saber que os primeiros Crays tinham problemas como esse.

free aceita apenas ponteiros não-const como parâmetro. Portanto, no caso de ponteiros const, é necessária a conversão explícita para um ponteiro não const.

Não é possível liberar ponteiros const em C