Aufgabe 5


PATH_MAX (bzw. auch NAME_MAX) stehen im POSIX Standard als optional
drin, d.h. diese Makros muss es nicht geben. Wenn die Makros nicht definiert
sind, können die Werte über die Funktion pathconf (steht in POSIX)
abgefragt werden. Bei der Funktion ist aber AFAIK auch nicht garantiert,
dass sie erfolgreich zurückkehrt. oder der Wert, den man abfragen wollte,
kann “unendlich” sein. Er kann auch vom zugrundeliegenden Dateisystem
abhängen.

Wenn man es also “total portabel” machen möchte, müsste man überprüfen,
ob PATH_MAX definiert ist. Wenn ja, diesen Wert verwenden. Ansonsten
findet man den Wert über pathconf raus. Liefert pathconf einen Fehler
oder ist der Wert potentiell unbeschränkt, dann muss man sich etwas
anderes einfallen lassen.

Mir reicht es aber, wenn ihr ganz normal PATH_MAX verwendet, so als ob
es überall definiert wäre.

Oder man bastelt sich den Pfad zu den Dateien im auszugebenden Verzeichnis über einen dynamisch allokierten Puffer zusammen, dann
umgeht man die angesprochenen Probleme.


Wie wird denn nun die Aufgabe bewertet?
Muss ich jedes Release von 1 bis 4 einzeln nochmal durchgehen und evtl. Fehler beheben, optimieren usw., oder wird nur das komplette printdir mit allen Funktionen (Release #4) bewertet?


Afaik sollst du mit den Releases eben das RCS üben.
Aber wenn das in der Aufgabenstellung so gefordert ist, dann werden wohl auch die anderen Releases geprüft.


Wichtig ist, dass in den einzelnen Releases die Aufgabe den jeweils zur Teilaufgabe passenden Stand erreicht hat. Wenn ihr dann am Ende in eurem neusten Release noch einen Bug findet der sich zurueck in die alten Releases zieht dann ist es nicht noetig diesen extra noch einmal in jedem Release zu fixen und das dann als neuen Branch einzuchecken. Uns kommt es eigentlich nur darauf an, dass ihr erste Erfahrungen mit einem sehr einfachen Versionskontrollsystem sammelt…


Na hättest das mal früher gesagt :slight_smile:


Ich hab ein Problem.
Also mein Prog komiliert und führt auch wie gewollt alles aus, also die Verzeichniseinträge werden korrekt ausgegeben nur nach der Ausgabe kommt immer diese Meldung

Inconsistency detected by ld.so: dl-fini.c: 58: _dl_fini: Assertion `i < _rtld_local._dl_nloaded’ failed!

mit der ich eigentlich nix anfangen kann.
Kann mir da vllt jemand weiterhelfen, danke.

Edit: Hat sich mittlerweile erledigt, hab die Fehler beseitigt.


Naja, erzähl doch mal was du genau gemacht hast. Vll. haben andere auch mal diesen Fehler.


Ist es nötig bei der Ausgabe des Verzeichnisnamens diesen aufzulösen? Ich meine z.B. wenn man . oder … übergibt. Mein print dir gibt dann momentan einfach

.:
/* Verzeichnisinhalt des aktuellen Verzeichnisses */

aus. Ist das ausreichend? Wenn man z.B. ~ angibt, wird das bereits von der Shell aufgelöst wie es scheint, das ist kein Problem.

Wie habt ihr das gelöst?


Ich hab einfach . oder … ausgegeben.
Wie’s mein Partner gemacht hat weiß ich atm nicht.


AAAahahahhhhhahhahahhahahah! :wand: :wand: :wand:

Naja besser spät als nie :wink:


Was heißt Bug genau?
Beispielsweise hab ichs erst in Release 3 eingeführt dass Speicher für die Structs,wo bei mir eben die ganzen Datei-Attribute drin stehn,dynamisch nachgfordert wird.In den ersten beiden Releases kann er halt dann z.B. nicht beliebig große Verzeichnisse ausgeben.
Weiterhin fehlt evtl. noch die ein oder andere Fehlerabfrage.

Wäre das also okay wenn in Release 4 dann letztendlich alles passt,bei den andern aber obige Fehler (oder ähnliche) drin wären?


Letztendlich ist es doch so, dass wir einfach wollen, dass ihr ein bisschen mit RCS rumspielt und lernt es zu benutzen. Erfahrungsgemaess ist es eben so, dass die Leute den Stoff in der Uebung hoeren und es dann nie ausprobieren und schnell wieder vergessen. Ihr werdet aber im Laufe eures Studium ganz sicher noch Versionskontrolle (nicht unbedingt RCS) brauchen, in SoS2 wird das (falls sich nichts geaendert hat) sogar die einzige Form der Abgabe sein. Wir versuchen euch also in irgendeiner moeglichst sinnvollen Form dazu zu zwingen RCS zu benutzen – und das ist bei den kleinen Aufgaben nicht immer einfach; daher bietet es sich eben an einzelne Versionen fuer die Teilaufgaben zu verwenden um in irgendeiner Form eine Vorgabe zu haben.
Was wir also sehen wollen ist einfach, dass ihr RCS verwendet habt und eben nicht nur die fertige Aufgabe 5x nacheinander eincheckt. Deshalb macht es auch keinen Sinn fuer einen Bug alle alten Versionen wieder zu aktualisieren, das wuerde man in der Praxis ja auch nicht machen, ausser natuerlich es existiert wirklich ein seperater Zweig der noch entwickelt/verwendet wird in dem der Fehler eben auch ausgebuegelt werden muss.
Wir werden zur Bewertung also ohnehin das letzte Release hernehmen und an den Zwischenreleases nur anschauen ob sie dem geforderten Teilaufgabenstand entsprechen, aber wir werden in den alten Releases nicht nach Fehlern suchen. Also @comrade, auch das nicht dynamische Nachfordern von Speichern wuerde ich in diesem Sinne als Bug betrachten :wink:


Naja hab schon weng was geändert, waren paar Fehler drin beim speicher anfordern mit malloc.
aber warum diese meldung kam weiss ich noch immer ned.