Untypischer Laufzeitfehler durch malloc()

[SeppJ]

@EL-europ sagte in Untypischer Laufzeitfehler durch malloc():

@DirkB
Bedeutet das jetzt das der Compiler von alleine versteht das hier "i != 0" gemeint ist, und man immer einfach die Zählvariable schreiben kann wenn man "Zählvariable != 0" meint?

Ja. Siehe auch ein anderer kürzlicher Beitrag von dir zum Thema if (filestream). Wobei diese Schreibweise aber ungewöhnlich ist um Integervariablen auf Gleichheit mit 0 zu vergleichen, würde ich in einem Codereview ankreiden. Besonders wenn der autor nicht einmal selber weiß, warum es das macht.

[EL europ]

@SeppJ
Danke für die Antwort. Als Neuling in c ist solch ein Schleifenkopf fragwürdig. Da liest man schon gerne das er solch eine "Gültigkeit" hat

[DirkB]

@EL-europ i != 0 ist ein sog. Ausdruck. Eine Berechnung, die ein Ergebnis liefert.
In diesem Fall eine 1 (für wahr), wenn i ungleich 0 ist und
0 (für unwahr), wenn i gleich 0 ist.

In C gilt 0 als unwahr, alles andere als wahr.

i ist auch ein Ausdruck und liefert den Wert von i

Ein Funktionsaufruf liefert auch einen Wert. (sofern die Funktion einen Rückgabewert hat)

[hustbaer]

@EL-europ
Hätte ich eigentlich schon beantwortet gehabt: https://www.c-plusplus.net/forum/topic/352442/untypischer-laufzeitfehler-durch-malloc/55

[Swordfish]

@SeppJ sagte in Untypischer Laufzeitfehler durch malloc():

Wobei diese Schreibweise aber ungewöhnlich ist um Integervariablen auf Gleichheit mit 0 zu vergleichen, würde ich in einem Codereview ankreiden.

Ich verstehe ehrlichgesagt nicht warum es so ungewöhnlich sein soll. Jemandem der die Sprache versteht ist die Bedeutung doch sofort klar.

[hustbaer]

@Swordfish Ich schätze mal dass es ungewöhnlich ist weil es sich für die meisten Leute komisch anfühlt.
if (flags) fühlt sich OK an.
if (number_of_elements) fühlt sich auch noch OK an.
if (x_coordinate) fühlt sich komisch an.
Und if (index) fühlt sich für mich halt auch komisch an. Speziell wenn es in einer Schleife auftaucht die von N-1 bis 1 laufen soll. Weil allein das schon ungewöhnlich ist. Die meisten Schleifen laufen halt von 0 bis N-1, ein paar wenige von N-1 bis 0, aber extrem wenige von N-1 bis 1.

[SeppJ]

Es ist ungewöhnlich, weil hier von der Logik her "ungleich dem Wert 0" abgefragt werden soll, aber (bool) i ist von der Semantik her "ist i wahr?". Nun sind philosophische Wahrheit und die Integerwerte 0 und 1 in C technisch gesehen das gleiche, aber das ist eigentlich nur Willkür bei der Definition der Sprache. Daher würde ich bemängeln, wenn man diesen zufälligen Umstand ausnutzt. Reduction ad absurdum: i - true bedeutet auch das gleiche wie i - 1 und nutzt den gleichen Sprachmechanismus aus. Wie würdest du auf so etwas im Code reagieren?

[EL europ]

@hustbaer @DirkB
Ich hab den Zusammenhang nicht herstellen können. Das ist das erste mal das ich solch einen Schleifenkopf sehe, zumindest ohne einen Schreibfehler vermuten zu können. Aber für das hab ich mich ja hier angemeldet
Dank allen die mir geholfen haben.

[*john 0]

@EL-europ sagte in Untypischer Laufzeitfehler durch malloc():

@john-0
Das Funktioniert so wie du schreibst. Doch in dem Übungsprogramm
steht '#if defined MSC_VER ... #elif defined linux' und ich hab kein -D__linux_ beim kompilieren gesetzt. Aber er hat den Code nach linux eingesetzt. Gibt es irgend eine Datei in welcher der Präprozässor standardmäßig Variablen wie z.B. _MSC_VER oder linux abfragt oder hat er die "in sich"? er muss ja irgendwo linux bei mir gefunden haben, sonst hätte der Aufruf der Sleep-Funktion beim compilieren einen Fehler ausgelöst.

Variablen und Präprozessor Definitionen, die mit __ anfangen sind immer vom Compiler bzw. der Laufzeitumgebung definiert. Das kann über Compiler bzw. System Header erfolgen, oder der Compiler definiert die Sachen intern, das gibt die Norm nicht vor.

Mein Beispiel sollte nur zeigen, dass man leicht selbst solche Defines machen kann, und sie ebenso leicht auswerten kann. In der Realität würde man natürlich vom System definierte Präprozessor Variablen nutzen, um die Unterscheidung zwischen Windows und Linux zu machen. Nur wäre für ein Anfänger ein Ausflug in POSIX und die diversen Versionen erstmal kontraproduktiv.

[EL europ]

@john-0
Danke dir für den Tip mit der Compileroption -D und #ifdef im Code. Vielleicht kannst du mir nochmal helfen? Ich hab in den Sourcen der curses lib gestöbert und versteh nur Bahnhof. Die einzelnen Funktionen in einen Zusammenhang zu bringen ist mir nicht möglich. Aber mir fiel wieder ein dort sehr häufig vorkommendes Konstrukt auf das ich nicht verstehe

return(*(int *)0);

Wird hier die 0 auf einen int-Zeiger gecastet und dann wieder der Wert 0 des Zeigers zurückgegeben? Warum gibt man hier nicht einfach 0 zurück?

[EL europ]

@john-0
Ach, und danke dir auch das ich nun weiss das Variablen in den Headerdateien und im Compiler selbst vorhanden sind

[wob]

@EL-europ sagte in Untypischer Laufzeitfehler durch malloc():

Aber mir fiel wieder ein dort sehr häufig vorkommendes Konstrukt auf das ich nicht verstehe
return(*(int *)0);

Wird hier die 0 auf einen int-Zeiger gecastet und dann wieder der Wert 0 des Zeigers zurückgegeben? Warum gibt man hier nicht einfach 0 zurück?

Zunächst fällt doch auf, dass die Dateien, wo das vorkommt, mit "llib-" anfagen und keine .c oder .h-Erweiterung haben. Ich habe jedenfalls als erstes mal in die ncurses/README-Datei geschaut. Und siehe da, es gibt dort genau einen Absatz - und der bezieht sich auf diese Dateien.

Der Code dereferenziert einen Null-Pointer und gibt somit nicht 0 zurück, sondern verursacht undefiniertes Verhalten. Das ist dort Absicht. Das soll für "Linting" sein. Also vermutlich soll man die Funktionen nicht (mehr?) verwenden und wenn doch, kannst du mit -Wnull-dereference sehen, wo du etwas verwendest, das du nicht verwenden sollst.

Jedenfalls: ich hätte mir mehr Information aus der README erhofft, wie ich diese Dateien benutzen soll - denn in meinem Programm will ich die ja sicher nicht haben - wahrscheinlich müsste ich dazu die vollständige Doku lesen.

[EL europ]

@wob
Also gibt die Funktion einen uninitialisierten Speicherbereich zurück? Für mich ist das ein "harter Brocken" bewusst undefiniertes Verhalten zu erzwingen, außer man kann es irgendwo "abfangen"
Das Readme hab ich angefangen zu lesen aber dann abgebrochen weil ich die curses eigentlich cross-compilieren will und mit dem readme und meinem knappem Englisch nicht weiter kam. Danke für deine Antwort

[wob]

@EL-europ sagte in Untypischer Laufzeitfehler durch malloc():

Also gibt die Funktion einen uninitialisierten Speicherbereich zurück? Für mich ist das ein "harter Brocken" bewusst undefiniertes Verhalten zu erzwingen, außer man kann es irgendwo "abfangen"

Sie gibt keinen "uninitialisierten Speicherbereich zurück".

Es ist ganz einfach undefiniert, was passiert. Das Programm darf crashen, der Compiler kann den Code auch ganz löschen usw. Der Compiler dürfte theoretisch auch Code einbauen, der deine Festplatte formatiert (wird er nicht tun).

Diese Libraries sind nicht zum Benutzen durch den Enduser gedacht, sondern für einen Linter.

Aber ich muss sagen, dass ich mich hiermit nicht auskenne. Vielleicht missverstehe ich das auch. Jedenfalls sind das dort ja alles nur leere Funktionen - auch die, die keinen Nullpointer dereferenzieren, haben ja einen leeren Body. Mit ist nicht klar, wozu das gut sein soll. Vielleicht kann sich ein C-Experte dazu äußern?

[DirkB]

@wob sagte in Untypischer Laufzeitfehler durch malloc():

Diese Libraries sind nicht zum Benutzen durch den Enduser gedacht, sondern für einen Linter.

Der bekannteste dürfte lint sein: https://de.wikipedia.org/wiki/Lint_(Programmierwerkzeug)?wprov=sfti1

[EL europ]

@wob Sorry, das fällt mir äußert schwer. Die "naive" Logig verbietet es doch Code zu Schreiben der nicht benutzt werden soll.
Kannst du mir einen Tip geben wie ich die curses auf meinem Linux, in eigenen Programmen für arm als statische lib nutzen, compilieren kann? Eine eigene trivial-lib hab ich schon einbinden können, aber curses: Da gibts Hinweise zu Konfigurieren und compilieren die ich nicht verstehe.

[wob]

Hier zur Historie von llint-* in ncurses: https://invisible-island.net/personal/lint-tools.html

[Th69]

@EL-europ: Die "llib-"-Dateien sind nicht der Source-Code der Library, sondern dienen, wie schon geschrieben, nur zur statischen Code-Analyse (d.h. man kann damit seinen eigenen Code überprüfen lassen, ob die Aufrufe der ncurses-Library Funktionen korrekt sind, s. z.B. lint Libraries).

Der eigentliche Source-Code der ncurses-Library befindet sich in den Unterordnern (d.h. die ".c"- und ".h"-Dateien).

[wob]

@EL-europ sagte in Untypischer Laufzeitfehler durch malloc():

Die "naive" Logig verbietet es doch Code zu Schreiben der nicht benutzt werden soll.

... der nicht vom Benutzer der Library benutzt werden soll. Der aber sehr wohl von einem Tool benutzt werden soll, das Checks durchführt.

[EL europ]

@DirkB ich habs eben mal ausprobiert, an der Stelle wo

(*(int *)0);

zugewiesen wird bricht das Programm mit einen Speicherzugriffsfehler ab. Was ist Lint?