[ueb1] Fragethread


Dürfen wir math.h verwenden? Für manche Funktionen braucht man da scheinbar noch das -lm Flag zum linken. Soll man ne Makefile mit abgeben oder die Flags irgendwo angeben?


Wofür möchtest du die denn verwenden?


Für Aufgabe 1 brauchste noch keine Makefile - ich hab aber dennoch eine abgegeben da ich ja selbst eine nutze.

Und wirklich - was hast du mit math.h vor?


Mir gibt valgrind nen Fehler aus, ich weiß aber nicht wirklich, was ich damit anfangen soll. Ich poste den (hoffentlich) relevanten Teil:

remove: 47
remove: 11
==3547== Conditional jump or move depends on uninitialised value(s)
==3547== at 0x400693: remove_element (in /home//C/aufgabe1/queue)
==3547== by 0x400720: main (in /home/
/C/aufgabe1/queue)
remove: 42
remove: -1
remove: 13

Dann hab ich noch ne zweite Frage:
Ist es sinnvoll/nötig zu checken, ob der übergebene Int-Wert, der in die Liste eingetragen werden soll, auch ein Intwert ist? (Also zu überprüfen, ob es eine nicht Fließkommazahl ist, die einen gewissen Wert nicht überschreitet. 2³²/2, wenn ich mich nicht täusche)


Mit math.h wollte ich die Länge eines Strings für die Implementierung von int2string abschätzen.


klavi: Nein, du musst das nicht überprüfen, weil dein int erst gar nicht größere Werte
als INT_MAX (definiert in limits.h) annehmen kann.

andy: Ich nehme an, du willst einen Integer als String ausgeben? Mach das
einfach mit printf(“%d”, i), bzw. schau dir mal die die manpage zu printf(3) an :wink:


Wenn dann mit sprintf in String umwandeln, aber es geht mir hier erstmal nur darum ob wir math.h benutzen dürfen.


@klavi:
Die Fehlermeldung von valgrind bedeutet, dass du eine if-Abfrage oder eine Schleifen-Bedingung hast, in der du eine uninitialisierte Variable verwendest. Und zwar in der Funktion remove_element(). Kompillierst du mit dem gcc-Flag -g ? Weil valgrind eigentlich Zeilennummern ausgibt. Das hilft bei der Fehlersuche ungemein. :wink:

@andy:
Bitte daran denken, dass sprintf eine gefährliche Funktion ist, die man besser nicht verwenden sollte. Wenn du einen int in einen String kopieren willst (wozu auch immer bei der Aufgabe…), dann verwende snprintf und gib die maximale Länge deines Arrays an. Bei sprintf könnte es passieren, dass du einen Überlauf deines Puffers produzierst.
EDIT
Vergiss das mit snprintf. Ich habe gerade gesehen, dass die Funktion erst in C99 definiert ist… Damit fällt sie für SoS flach. Aber für später merken. :wink:
/EDIT
Grundsätzlich zum Thema zusätzliche Bibliotheken einlinken: Das ist eher keine gute Idee, zumindest bei der ersten Aufgabe nicht. Dein Programm wird ja ohne Makefile abgegeben (wenn du eines abgibst wird es ignoriert). Damit wird dein Programm nach der Abgabe wahrscheinlich nicht automatisch kompillieren…
Und für eine Lösung der Aufgabe braucht man auch keinerlei Tricks. Es gibt noch genügend Aufgaben zum austoben. :wink:


Und wie wird das bei den nächsten Aufgaben laufen?


Bei Aufgabe 2, die inzwischen online ist, muss man seinen eigenen Makefile erstellen und den zusammen mit seinem Quellcode abgeben. Da sollte man dann also an Bibliotheken verwenden können, was man will.


thx IceWeasel, mit -g beim Kompilieren war dann der Fehler doch recht schnell zu finden. Gibts eigentlich nen vernünftigen (OpenSource) Debugger, mit dem man auch grafisch arbeiten kann, nachdem ich jetzt schon mit -g kompiliere? Oder MUSS man als angehender C Profi hust mit dem gdb umgehen können? Im Moment wirkt der auf mich nonet so vertrauenserweckend.


auf die Pufferueberlaufproblematik und die sprintf-Problematik und snprintf gehen wir in den Uebungen noch ein.
wg. snprintf und C99: snprintf ist ja erheblich aelter - nur die Tatsache, dass C99 es in seine
Normierung aufgenommen hat ist deshalbt kein Grund es nicht benutzen zu duerfen.
Bei C99 muss man zwei Sachen unterscheiden: Spracherweiterungen und das ganze drum herum - also Funktionsbibliotheken.
Wir werden oefters Funktionen nutzen, die weder ANSI-C noch POSIX sind -
das ist oft nicht vermeiden bzw. einfach besser. Durch unsere strenge Fokussierung
auf ANSI und POSIX am Anfang merkt man das dann aber und es wird einem mehr bewusst,
wieviele unterschiedliche Standards es in dieser Umgebung tatsaechlich gibt (und was das
fuer die Portierbarkeit von Software bedeuten kann).


Willkommen bei C! Was da passiert ist, dass der Funktion ein Speicherbereich uebergeben wird und dieser als Integer interpretiert wird. Du als Programmierer hast also keine Moeglichkeit zu ueberpruefen, ob der Aufrufer von deiner Funktion da irrtuemlich eine Fliespunktzahl rein gesetzt hat, die bits dieser Flieskommazahl wuerden einfach komplett anders interpretiert werden, wenn man nicht castet (was auch implizit passieren kann). Das kann allerdings der Compiler, der entsprechende Warnung ausspuckt, wenn du z.B. eine long Variable als int einsetzt oder eben hier nicht castest.

Aber du hast Recht, dass es da eine Problematik gibt und darum sollte man bei jedem cast sich klar machen, was da ueberhaupt passiert. Speziell mit Pointer kann man sehr schnell Unfug treiben.


Du kannst eclipse mit CDT benutzen, dann kriegste du ein GUI Frontend für den gdb.

ddd

Es gibt ddd, aber mehr dazu sagen kann ich nicht, ich war mit dem gdb eigentlich recht zufrieden.


Jop, ich nutze auch Eclipse und CDT.
Die GUI vom Debugger setzt auf dem gdb auf und das Ganze ist super einfach zu bedienen.

Leider rallt Eclipse STRG+D nicht - was sehr hinderlich ist, wenn man bis EOF einlesen möchte…