Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 4 - clash
Kurze Frage: Gibt es eine maximale pid, die beim forken zurückgegeben wird? Bzw. wie groß ist die?
Naja, ein [m]pid_t[/m] ist nicht beliebig groß, also gibt es eine maximale PID. Die ist allerdings systemspezifisch (könnte mal ein 16-bit signed integer, mal ein 32-bit unsigned integer sein). Wozu brauchst du denn die maximale PID?
Laut POSIX ist es (also der Rückgabetyp [m]pid_t[/m]) ein ganz normales (signed) [m]int[/m], darf also theoretisch alle Werte annehmen (auch wenn das auf einem System konkret begrenzt sein kann durch Speicher etc.).
Wenn sich dein System nicht an den Standard hält wären noch bis zu [m]long long[/m] (in C99) als größtmöglicher Datentyp möglich, dann wäre [m]sizeof(pid_t) == sizeof(long long)[/m].
Wenn du’s wegen SP überprüfen und dann in ein [m]int[/m] stecken willst würde ich das an deiner Stelle einfach nicht so tun sondern [m]pid_t[/m] verwenden.
Ich wollte mir für meine Hintergrundprozesse ein array anlegen um den Befehl, den ich einem bestimmten Prozess übergebe an dem index der pid zu speichern, damit ich das dann beim Exitstatus wieder ausgeben kann, da mein remove Element ja nur das command aber nicht den Rest zurück gibt.
Aber wenn es sich dabei um 16-32 bit handelt wird das wohl so nichts 
Ohne zu Validieren ob das sinnvoll ist was du tust - leg doch den Array auf den Heap ([m]malloc[/m]) und erweitere ihn dynamisch. 
Klingt fast so, als sei es nicht sinnvoll 
Aber danke, hatte ganz vergessen, dass das in C ja geht 
Ich weiß nur noch, dass ich das damals nicht gebraucht habe - aber ich hab weder die Änderungen der Aufgabenstellung noch sonst was diesbezüglich im Kopf. 
Das Array könntest du ja aus Elementen vom Typ eines structs erstellen, welches jeweils eine PID und Variablen für deine Daten besitzt. Du musst dann nur noch das Element mit der richtigen PID aus dem Array suchen, das ist halt kein O(1) - aber hier wäre das ja egal.
Ich werd nochmal genau drüber nachdenken, wie ich das jetzt am elegantesten löse… Vielen Dank für die Hilfe
Das stimmt so nicht ganz. Da steht nur, dass sie „shall be signed integer types“. Über die Größe steht da noch nichts.
Oh, also mit „integer types“ sind sämtliche short/int/long gemeint? (Unter anderem [m]int[/m]…)
Hab das irgendwie mit [m]int[/m] gleichgesetzt.
Dann müsste man natürlich - um die Größe zu ermitteln - auf alle möglichen sizeof(…)s für Integers prüfen, wenn man vor hat die Daten aus pid_t-Variablen in Integers zu speichern. In C99 kommt ja z.b. noch das long long dazu.
Aber ist ja anscheinend nicht mehr nötig. 
Die Fragestellung verwirrt mich grad ziemlich. 
Warum genau sollte die [m]plist[/m] für deine Zwecke nicht ausreichen? [m]removeElement()[/m] gibt dir genau das zurück, was du vorher in die [m]plist[/m] reingestopft hast. Wenn du die gesamte (unzerschnippelte) Befehlszeile reinsteckst, kommt sie später auch wieder unverändert und heil raus.
Okay… Ich saß wohl heute schon zu lange vor der Aufgabe… Darauf hätte ich eigentlich selber kommen sollen
Danke für den Hinweis, das erspart mir eine Menge Ärger
Ich habe eine Frage, die eigentlich nicht wirklich die Aufgabe betrifft.
Im CIP-Pool funktioniert die Ausgabe des Verzeichnisses mit [m]getcwd()[/m] optimal. Wenn ich exakt die gleiche Datei daheim auf meinem PC mit Ubuntu 12.04 ausfuehre, wird jedes mal null ausgegeben.
Also habe ich in die man-page von getcwd(3) geschaut. Da steht irgendwas von glibc 2.12. Wenn ich [m]apt-cache show libc6[/m] auf der Konsole ausfuehre, sind die ersten paar Zeilen:
“Package: libc6
Priority: required
Section: libs
Installed-Size: 10417
Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com
Original-Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org
Architecture: amd64
Source: eglibc
Version: 2.15-0ubuntu10.5
Replaces: belocs-locales-bin, libc6-amd64
Provides: glibc-2.13-1 …”
Die Version sollte also ausreichen oder? Habt ihr irgendeine Idee, woran das liegen koennte? Denn ich habe wenig Lust, nur im CIP-Pool das Programm bearbeiten zu koennen.
Du darfst [m]getcwd(3)[/m] nicht mit [m]NULL[/m] benutzen, da dies nicht in POSIX spezifiziert ist:
Bei der Fehlerabfrage solltest du auch mit [m]perror(3)[/m] die Fehlermeldung ausgeben, dann ist auch klar was kaputt geht.
Besten Dank. Auf die Idee bin ich natuerlich nicht gekommen …
Als Fehlermeldung kam: [m]getcwd: Numerical result out of range[/m]. Wenn ich nun die clash in einem Verzeichnis ausfuehre, dessen Pfad nicht so lang ist, dann funktioniert es.
Wenn die Man-Page zu diesem Thema Folgendes zu sagen hat, …
ERANGE The size argument is less than the length of the absolute path‐
name of the working directory, including the terminating null
byte. You need to allocate a bigger array and try again.… dann solltest du dich daran auch halten und eine Schleife um das [m]getcwd()[/m] bauen, die das Ziel-Array im Zweifelsfall vergrößert (z. B. um einen konstanten Faktor).
Das ist zugegebenermaßen ein kleines bisschen pfriemelig, aber trotzdem sehr wichtig. Eine Shell, die mit einer Fehlermeldung abschmiert, weil der Benutzer ein kleines bisschen tiefer im Verzeichnisbaum absteigen möchte, ist nun mal unbenutzbarer Käse.
Ich bin gerade dabei, valgrind zufriedenzustellen. Leider habe ich ein paar mal alloc() oefter als free(). Kann es sein, wenn ich eine Variable [m]char* prompt [/m] habe und zwei mal [m]realloc()[/m], aber nur einmal [m]free[/m] auf sie aufrufe, dass valgrind das als zwei mal alloc und nur einmal free zaehlt?
Wenn ja, wie kann ich valgrind dann gluecklich machen?
Nachdem realloc den alten Speicherbereich freigibt (siehe manpage), sollte es da zu keinen Problemen kommen.
Valgrind zählt ja nicht, wie oft du malloc() und free() aufgerufen hast sondern beobachtet, welcher Speicher belegt ist.
Du musst also noch wo anders einen Fehler haben.
Nach langem Suchen habe ich den Uebeltaeter, [m]getcwd[/m], gefunden. Ich habe die char* Variable, in die ich den Pfad mittels getcwd() speichere, nun mit NULL initialisiert, da dann getcwd() in meiner Schleife automatisch so oft malloc() und free() aufruft, bis der Speicher ausreicht. Nur das allerletzte free() muss ich selbst durchfuehren.
EDIT: Wenn ich getcwd() in char* prompt in einer while Schleife speichere, die solange laeuft, bis in prompt etwas ungleich NULL steht. Wie kann ich dann die Fehlerueberpruefung fuer getcwd() durchfuehren?