Überprüfung auf NULL, bevor Sie kostenlos anrufen

Viele Aufrufe zum Freigeben von Zeigern in C-Code:

if (p)
  free(p);

Aber wieso? Ich dachte, C-Standard sagen die free Die Funktion macht bei einem NULL-Zeiger nichts. Warum also noch eine explizite Prüfung?

Das Konstrukt:

free(NULL);

war in C immer in Ordnung, zurück zum ursprünglichen UNIX-Compiler, der von Dennis Ritchie geschrieben wurde. Vor der Standardisierung haben einige schlechte Compiler es vielleicht nicht richtig eingesetzt, aber heutzutage kann sich jeder Compiler, der sich nicht als Compiler für die C-Sprache bezeichnen darf, legitimerweise nicht nennen. Die Verwendung führt in der Regel zu klarerem, besser wartbarem Code.

Soweit ich weiß, war das No-Op auf NULL nicht immer da.

In den schlechten alten Tagen von C (damals um 1986 auf einem cc-Compiler vor dem ANSI-Standard) würde free(NULL) den Kern ausgeben. Daher haben die meisten Entwickler auf NULL/0 getestet, bevor sie kostenlos angerufen haben.

Die Welt hat einen langen Weg zurückgelegt, und es scheint, dass wir den Test nicht mehr durchführen müssen. Aber alte Gewohnheiten sterben schwer;)

http://discuss.joelonsoftware.com/default.asp?design.4.194233.15

Ich neige dazu zu schreiben “if (p) free(p)„viel, auch wenn ich weiß, dass es nicht nötig ist.

Ich mache mir teilweise selbst Vorwürfe, weil ich früher C gelernt habe free(NULL) würde segfault und ich fühle mich immer noch unwohl, es nicht zu tun.

Aber ich beschuldige auch den C-Standard, nicht konsistent zu sein. Wäre zum Beispiel fclose(NULL) wohldefiniert, hätte ich keine Probleme beim Schreiben:

free(p);
fclose(f);

Was beim Aufräumen sehr oft vorkommt. Leider kommt es mir seltsam vor zu schreiben

free(p);
if (f) fclose(f);

und ich am Ende mit

if (p) free(p);
if (f) fclose(f);

Ich weiß, es ist kein rationaler Grund, aber das ist mein Fall 🙂

Compiler sind selbst beim Inlining nicht intelligent genug, um zu wissen, dass die Funktion sofort zurückgegeben wird. Das Schieben von Parametern usw. auf den Stapel und das Einrichten des Aufrufs ist offensichtlich teurer als das Testen eines Zeigers. Ich denke, es ist immer eine gute Praxis, die Ausführung von irgendetwas zu vermeiden, selbst wenn es sich um eine No-Op handelt. Das Testen auf null ist eine gute Praxis. Eine noch bessere Vorgehensweise besteht darin, sicherzustellen, dass Ihr Code diesen Zustand nicht erreicht, und somit die Notwendigkeit für den Test insgesamt zu eliminieren.

Es gibt zwei verschiedene Gründe, warum eine Zeigervariable NULL sein kann:

1. weil die Variable für das verwendet wird, was in der Typentheorie als an bezeichnet wird Optionstypund enthält entweder einen Zeiger auf ein Objekt oder NULL zur Darstellung nichts,

2. weil es auf ein Array zeigt und daher NULL sein kann, wenn das Array eine Länge von Null hat (wie malloc(0) darf NULL zurückgeben, implementierungsdefiniert).

Obwohl dies nur eine logische Unterscheidung ist (in C gibt es keine Optionstypen auch nicht besonders Zeiger auf Arrays und wir verwenden für alles einfach Zeiger), sollte immer deutlich gemacht werden, wie eine Variable verwendet wird.

Das verlangt die C-Norm free(NULL) Nichtstun ist das notwendige Gegenstück dazu, dass ein erfolgreicher Aufruf dazu führt malloc(0) kann zurückkehren NULL. Es ist nicht als allgemeine Annehmlichkeit gedacht, weshalb zum Beispiel fclose() tut erfordern ein Nicht-NULL-Argument. Missbrauch der Anruferlaubnis free(NULL) Durch das Übergeben einer NULL, die kein Array der Länge Null darstellt, fühlt es sich hackisch und falsch an.

Wenn Sie sich darauf verlassen, dass free(0) OKAY ist und es normal ist, dass Ihr Zeiger an dieser Stelle null ist, sagen Sie dies bitte im Kommentar // may be NULL

Dies kann nur ein selbsterklärender Code sein, der sagt ja ich weiß, ich benutze auch p als Flag.

Es kann eine benutzerdefinierte Implementierung von free() in der mobilen Umgebung geben. In diesem Fall kann free(0) ein Problem verursachen. (ja, schlechte Umsetzung)