Warum setzen einige Leute in C den Zeiger um, bevor sie ihn freigeben?

Question 1

Ich arbeite an einer alten Codebasis und so ziemlich jeder Aufruf von free() verwendet eine Umwandlung für sein Argument. Zum Beispiel,

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

wobei jeder Zeiger vom entsprechenden (und übereinstimmenden) Typ ist. Ich sehe überhaupt keinen Sinn darin, dies zu tun. Es ist ein sehr alter Code, also frage ich mich, ob es eine K&R-Sache ist. Wenn ja, möchte ich eigentlich die alten Compiler unterstützen, die dies möglicherweise erfordert haben, also möchte ich sie nicht entfernen.

Gibt es einen technischen Grund, diese Besetzungen zu verwenden? Ich sehe nicht einmal einen pragmatischen Grund, sie zu verwenden. Was bringt es, uns an den Datentyp zu erinnern, bevor wir ihn freigeben?

EDIT: Diese Frage ist nicht ein Duplikat der anderen Frage. Die andere Frage ist ein Sonderfall dieser Frage, was meiner Meinung nach offensichtlich ist, wenn die nahen Wähler alle Antworten gelesen hätten.

Kolophon: Ich setze das Häkchen bei der Antwort, die einen Grund dafür angegeben hat, warum dies möglicherweise noch getan werden muss; Die Antwort, dass es sich um eine Vor-ANSI-C-Benutzerdefinierte handelt (zumindest unter einigen Programmierern), scheint jedoch der Grund zu sein, warum es in meinem Fall verwendet wurde. Wenn es zwei Häkchen zu geben gäbe, würden sie beide eins bekommen. Viele gute Punkte von vielen Leuten hier. Vielen Dank für Ihre Beiträge.

Question 2

Casting kann erforderlich sein, um Compiler-Warnungen aufzulösen, falls dies der Fall ist const. Hier ist ein Codebeispiel, das eine Warnung auslöst, ohne das Argument „free“ zu übertragen:

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

Und der Compiler (gcc 4.8.3) sagt:

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;

Wenn du benutzt free((float*) velocity); der Compiler hört auf zu meckern.

Question 3

Pre-Standard C hatte keine void* aber nur char*, also mussten Sie alle übergebenen Parameter umwandeln. Wenn Sie auf alten C-Code stoßen, finden Sie daher möglicherweise solche Umwandlungen.

Ähnliche Frage mit Referenzen.

Als der erste C-Standard veröffentlicht wurde, änderten sich die Prototypen für malloc und free von have char* zum void* die sie heute noch haben.

Und natürlich sind solche Casts in Standard-C überflüssig und beeinträchtigen nur die Lesbarkeit.

Question 4

Hier ist ein Beispiel, bei dem free ohne Cast fehlschlagen würde:

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

In C können Sie eine Warnung erhalten (haben Sie eine in VS2012). In C++ erhalten Sie einen Fehler.

Abgesehen von seltenen Fällen bläht das Casting den Code nur auf …

Bearbeiten:
Ich habe gecastet void* nicht int* um den Fehler zu demonstrieren. Es wird genauso funktionieren wie int* wird umgewandelt in void* implizit. Hinzugefügt int* Code.

Question 5

Alter Grund: 1. Durch die Verwendung free((sometype*) ptr)gibt der Code explizit den Typ an, der als Teil des Zeigers betrachtet werden soll free() Anruf. Die explizite Umwandlung ist nützlich, wenn free() wird durch ein (Do-it-yourself) ersetzt DIY_free().

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

EIN DIY_free() war (ist) eine Möglichkeit, insbesondere im Debug-Modus, eine Laufzeitanalyse des freigegebenen Zeigers durchzuführen. Dies wird oft mit a gepaart DIY_malloc() um Sätze, globale Speichernutzungszählungen usw. hinzuzufügen. Meine Gruppe verwendete diese Technik jahrelang, bevor modernere Tools auftauchten. Voraussetzung dafür ist, dass der zu befreiende Gegenstand nach der Art gegossen wurde, der er ursprünglich zugeteilt war.

Angesichts der vielen Stunden, die mit der Suche nach Speicherproblemen usw. verbracht wurden, würden kleine Tricks wie das Casten des Typs free’d beim Suchen und Eingrenzen des Debugging helfen.

Modern: Vermeiden const und volatile Warnungen wie von Manos Nikolaidis@ und @egur angesprochen. Ich dachte, ich würde die Auswirkungen der 3 beachten Qualifikanten: const, volatileund restrict.

[edit] Hinzugefügt char * restrict *rp2 per @R.. Kommentar

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

Question 6

Hier ist eine weitere Alternativhypothese.

Uns wurde gesagt, dass das Programm vor C89 geschrieben wurde, was bedeutet, dass es keine Art von Nichtübereinstimmung mit dem Prototyp von umgehen kann freeweil es nicht nur so etwas wie nicht gab const Noch void * Vor C89 gab es so etwas wie a nicht Funktionsprototyp vor C89. stdlib.h selbst war eine Erfindung des Komitees. Wenn sich die Systemheader die Mühe gemacht haben, zu deklarieren free überhaupt hätten sie es so gemacht:

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

Nun, der entscheidende Punkt hier ist, dass das Fehlen von Funktionsprototypen bedeutete, dass der Compiler dies tat keine Überprüfung des Argumenttyps. Es wendete die Standard-Argument-Promotions an (die gleichen, die immer noch für variadische Funktionsaufrufe gelten) und das war es. Die Verantwortung dafür, dass die Argumente an jeder Callsite mit den Erwartungen des Angerufenen in Einklang gebracht werden, liegt bei ihm völlig mit dem Programmierer.

Dies bedeutet jedoch noch nicht, dass es notwendig war, das Argument zu werfen free auf den meisten K&R-Compilern. Eine Funktion wie

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

sollte korrekt kompiliert sein. Ich denke, was wir hier haben, ist ein Programm, das geschrieben wurde, um mit einem fehlerhaften Compiler für eine ungewöhnliche Umgebung fertig zu werden: zum Beispiel eine Umgebung, in der sizeof(float *) > sizeof(int) und der Compiler würde nicht Verwenden Sie die entsprechende Aufrufkonvention für Zeiger, es sei denn, Sie setzen sie am Punkt des Aufrufs um.

Mir ist keine solche Umgebung bekannt, aber das bedeutet nicht, dass es keine gab. Die wahrscheinlichsten Kandidaten, die mir in den Sinn kommen, sind abgespeckte “Tiny C”-Compiler für 8- und 16-Bit-Mikros in den frühen 1980er Jahren. Ich wäre auch nicht überrascht zu erfahren, dass frühe Crays solche Probleme hatten.

Question 7

free akzeptiert nur nicht-konstante Zeiger als Parameter. Im Fall von konstanten Zeigern ist daher eine explizite Umwandlung in einen nicht konstanten Zeiger erforderlich.

Konstante Zeiger in C können nicht freigegeben werden