Ok, wieder da.
Alle NULLs durch 0s ersetzt, schon mal weniger Warnungen. Gut. Welche Warnung meintest du mit Schwerwiegend? Ich habe jetzt noch einige mit

Code :

1	Warnung: Format ist kein Zeichenkettenliteral, und keine Formatargumente [-Wformat-security]

und

Code :

1	Warnung: veraltete Konvertierung von Zeichenkettenkonstante in »char*« [-Wwrite-strings]

und noch den hier:

Code :

1	Warnung: Adresse der lokalen Variable »path« zurückgegeben [standardmäßig aktiviert]

Ich nehme jetzt einfach mal an, dass du Letzteren meintest.
Möglicherweise eine Frage, die gleich einige Flames auslösen wird:
Was ist da der Fehler bzw. weshalb soll das nicht gut sein?


Und sorry wegen dem NULL = 0, aber ich habe irgendwo mal gelesen, das es (in der stdio.h?) einen #define NULL 0 hat. Naja, Entschuldigung.

Und noch eine Frage dazu: Weshalb geht es denn, wenn ich einem Pointer ein 0 gebe (char* Funktion(){ return 0;})?
cwriter

Zitat von cwriter

Und noch eine Frage dazu: Weshalb geht es denn, wenn ich einem Pointer ein 0 gebe (char* Funktion(){ return 0;})?
cwriter

In dem Fall gibst du den Null-Pointer zurück. Was deepthroat meinte ist das strcmp einen Integer zurück gibt. Ein Int kann den Wert 0 annehmen, aber ein Zeiger kann nur auf 0 zeigen. Das ist wie, wenn du einem bool eine 1 gibst und es intern als true behandelt wird.

Zu stdio und NULL:
Warum schaust du nicht einfach nach?

Zu der Adresse von lokalen Variablen:
Wenn man in einer Funktion eine Variable macht (die kein Pointer ist bzw.
mit malloc/new angelegt wird, sondern einfach eine ganz normale Variable)
wird die automatsch am Funktionsende wieder entfernt.

Für den Returnwert wird also die Adresse genommen,
dann wird die Variable gelöscht,
dann gehts in main etc. weiter.

Und das greift dann mit der Adresse auf einem Speicherbereich zu,
in dem schon wieder was ganz anderes steht/stehen kann
(es kann zufällig auch gehen, wenn noch nichts überschrieben wurde.
Trotzdem nicht toll, weil man sich darauf nicht verlassen kann).

Wenn man in einer Funktion eine Variable macht (die kein Pointer ist bzw.
mit malloc/new angelegt wird, sondern einfach eine ganz normale Variable)

Und wenn nicht? Müsste man den Pointer dann ausserhalb der Funktion "befreien"?

cwriter

/EDIT
So. Zusätzlichen char* reingeschrieben -> keine Warnung mehr. Der letzte Typ:

Code :

1	Warnung: Format ist kein Zeichenkettenliteral, und keine Formatargumente [-Wformat-security]

Ist das eine wichtige Warnung?

Genau.
malloc/new-Zeug wird am Funktionsende nicht entfernt,
muss dann aber irgendwann selbst mit free/delete gelöscht werden.

Wirklich schön wäre das aber nicht.
Wenn schon, dann im main anlegen, per Parameter übergeben,
und dann nach Gebrauch auh wieder im main freigeben.
Da freigeben, wo es auch angelegt wurde.

Ich habe die Lösung.
1. Es lag nicht an den Warnungen
§1 Damit schliesst sich ein Fehler im Code *teilweise* aus.
2. Es lag auch nicht am Compiler (auch wenn Code::Blocks permanent eine 85kb statt 119kb Datei ausspuckt)
3. Es lag einfach nur an einer schrecklichen Dummheit.

Tja, wenn man im Code nach "\\" sucht, findet man so einiges...
Unix möchte aber "/" haben.

Also nochmal für alle, die dasselbe Problem haben (werden):
Windows schreibt Pfade mit \ (im Code "\\")
Unix schreibt Pfade mit / (im Code "/")

*schäm*

cwriter

Zitat von cwriter

Ich habe die Lösung.
1. Es lag nicht an den Warnungen

Das habe ich übrigens auch nicht behauptet.

Zitat von cwriter

§1 Damit schliesst sich ein Fehler im Code *teilweise* aus.

Hast du denn nun alle Warnungen beseitigt? Wie gesagt, es ist eine schwerwiegende dabei, die unter bestimmten Bedingungen einen Absturz verursacht.

Zitat von cwriter

2. Es lag auch nicht am Compiler (auch wenn Code::Blocks permanent eine 85kb statt 119kb Datei ausspuckt)

Statisch vs. dynamische Bibliotheken, Windows und Linux Binaries sind auch nicht wirklich dahingehend vergleichbar.

Zitat von cwriter

3. Es lag einfach nur an einer schrecklichen Dummheit.

Tja, wenn man im Code nach "\\" sucht, findet man so einiges...
Unix möchte aber "/" haben.

Also nochmal für alle, die dasselbe Problem haben (werden):
Windows schreibt Pfade mit \ (im Code "\\")
Unix schreibt Pfade mit / (im Code "/")

Windows kann übrigens auch mit einem / umgehen.

Ansonsten hast du uns aber wohl etwas für dumm verkauft.

Zitat von cwriter

Debugger: Keine Fehler
Fehler: Keine Ausgabe. Es wird nur 0x0 zurückgegeben, was der return am Ende ist.

Das kann so nie und nimmer stimmen, da das erste was du machst ein printf("*\n"); ist, welches definitiv ausgegeben wird wenn man das Programm startet - auch unter Linux.

Gut, wir wissen auch nicht wie du das Program gestartet hast (gehört zu einer Fehlerbeschreibung dazu...), könnte sein das du

Code :

1	./a.out </dev/null >/dev/null

ausgeführt hast. Dann ist aber klar, dass keine Ausgabe kam.

Gruß

Ja ok, das mit dem Asterisk habe ich irgendwie übersehen. Und ja, ich habe sämtliche Fehler beseitigt und auch auf der Windows-Variante ausgeglichen. So gesehen hat sich die Mühe gelohnt

Wie gesagt, es ist eine schwerwiegende dabei, die unter bestimmten Bedingungen einen Absturz verursacht.

Nur eine? :-P
Ich habe zwei gefunden

Gestartet habe ich übrigens mit

Code :

1

/.out.a

und je nachdem noch mit einigen Parametern.

Statisch vs. dynamische Bibliotheken, Windows und Linux Binaries sind auch nicht wirklich dahingehend vergleichbar.

Linux + Code::Blocks: 85kb
Linux + Terminal + g++: 119.5kb
Windows + Dev-Cpp + MinGW: 404kb

Gruss
cwriter

Zitat von cwriter

Und ja, ich habe sämtliche Fehler beseitigt und auch auf der Windows-Variante ausgeglichen. So gesehen hat sich die Mühe gelohnt

Nur eine? :-P
Ich habe zwei gefunden

Gut! Ich habe mir nicht jede Warnung angeschaut. Es waren zuviele

Zitat von cwriter

Gestartet habe ich übrigens mit

Code :

1

/.out.a

Äh?

Code :

1

./a.out

Zitat von cwriter

Linux + Code::Blocks: 85kb
Linux + Terminal + g++: 119.5kb
Windows + Dev-Cpp + MinGW: 404kb

Da mußt du dir von Code::Blocks / Dev-Cpp schon mal die g++ Optionen ausgeben lassen. Evtl. gestrippt (-s), auf Code-Größe optimiert (-Os), ohne Exceptions (-fno-exceptions), ohne Framezeiger (-fomit-frame-pointer) usw.

Gruß

Äh?

Ja genau. Ich sollte früher zu Bett gehen

Anderes Problem:
Kompiliert unter Ubuntu -> läuft
Versuch auf Cygwin: läuft nicht.

Code :

1	./a.out: cannot execute binary file

Was soll das schon wieder? Ich dachte, dass die verschiedenen Linux-Distributionen untereinander kompatibel sind?
BTW, läuft ein Linux Programm auch unter Macintosh?

Achja, und

Code :

1	-fexceptions

War tatsächlich unter Zusätzliche Optionen zu finden.
Gruss
cwriter

Zitat von cwriter

Anderes Problem:
Kompiliert unter Ubuntu -> läuft
Versuch auf Cygwin: läuft nicht.

Code :

1	./a.out: cannot execute binary file

Was soll das schon wieder? Ich dachte, dass die verschiedenen Linux-Distributionen untereinander kompatibel sind?

Ja, sind sie auch.

Nur, Cygwin ist kein Linux. Cygwin ist immer noch Windows (plus Unix-Kompatibilitäts-Bibliotheken).

Der Compiler unter Cygwin erzeugt auch kein a.out, sondern eine a.exe.

Zitat von cwriter

BTW, läuft ein Linux Programm auch unter Macintosh?

Nein, nicht ohne Rekompilation.

Zitat von cwriter

Achja, und

Code :

1	-fexceptions

War tatsächlich unter Zusätzliche Optionen zu finden.

-fexceptions ist eigentlich die Voreinstellung. Um die Größe des Binaries zu reduzieren, müßte es -fno-exceptions heißen.

Gruß