24.02.2013 Aufrufe

Einf ¨uhrung in UNIX - CIS

Einf ¨uhrung in UNIX - CIS

Einf ¨uhrung in UNIX - CIS

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

190 2 <strong>UNIX</strong><br />

fehler.c<br />

==============<br />

(36) warn<strong>in</strong>g: a may be used before set<br />

(41) syntax error<br />

(41) warn<strong>in</strong>g: ma<strong>in</strong>() returns random value to environment<br />

==============<br />

function returns value which is always ignored<br />

pr<strong>in</strong>tf scanf<br />

Zeile 41 ist das Programmende, dort steckt e<strong>in</strong> Fehler. Die Warnungen<br />

s<strong>in</strong>d nicht so dr<strong>in</strong>gend. Mit dem vi(1) ergänzen wir die fehlende geschweifte<br />

Klammer am Schluß. Der Fehler hätte uns eigentlich nicht unterlaufen<br />

dürfen, da der vi(1) e<strong>in</strong>e Hilfe zur Klammerprüfung bietet (Prozentzeichen).<br />

Neuer Lauf von l<strong>in</strong>t(1):<br />

fehler.c<br />

==============<br />

(36) warn<strong>in</strong>g: a may be used before set<br />

(33) warn<strong>in</strong>g: d unused <strong>in</strong> function ma<strong>in</strong><br />

(41) warn<strong>in</strong>g: ma<strong>in</strong>() returns random value to environment<br />

==============<br />

function returns value which is always ignored<br />

pr<strong>in</strong>tf scanf<br />

Wir werfen die überflüssige Variable d <strong>in</strong> der Deklaration heraus. Nochmals<br />

l<strong>in</strong>t(1).<br />

fehler.c<br />

==============<br />

(36) warn<strong>in</strong>g: a may be used before set<br />

(41) warn<strong>in</strong>g: ma<strong>in</strong>() returns random value to environment<br />

==============<br />

function returns value which is always ignored<br />

pr<strong>in</strong>tf scanf<br />

Jetzt ignorieren wir die Warnung von l<strong>in</strong>t(1) bezüglich der Variablen a<br />

(obwohl heimtückischer Fehler, aber das ahnen wir noch nicht). Wir lassen<br />

kompilieren und rufen das kompilierte Programm a.out(4) auf:<br />

cc fehler.c<br />

a.out<br />

Der Compiler hat nichts zu beanstanden. Ersten Summanden e<strong>in</strong>geben,<br />

Antwort: memory fault oder Bus error - core dumped. Debugger 40 e<strong>in</strong>setzen,<br />

dazu nochmals mit der Option -g und dem vom Debugger verwendeten<br />

40 Real programmers can read core dumps.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!