dschlueter
c6f2f1f8e0
python-calculator: PASS, 1:15 min, 1 Runde c-linkedlist: /quick_check 0:21 + /fix 0:50 + /patch 0:31 rust-wordcount: PASS WITH CONCERNS, 1:40 min, 1 Runde + /version v0.2.0 go-fibonacci: PASS + SHIP, ca. 3 min gesamt Hinweise: --interactive nicht mit --print kombinierbar; /version benötigt interaktiven UI-Dialog. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| linked_list.c | ||
| linked_list.h | ||
| main.c | ||
| PROTOKOLL.md | ||
| README.md | ||
C Linked List
Vollständige einfach-verkettete Liste — bis auf list_free(), das als leerer Stub vorliegt.
Jeder Programmlauf leckt den gesamten Listen-Speicher.
Aktueller Stand
linked_list.h Interface: node_new, list_prepend, list_append, list_print, list_free, list_length
linked_list.c Alles implementiert — außer list_free() (Stub, tut nichts)
main.c Baut Liste 1–5, gibt sie aus, ruft list_free() auf (ohne Wirkung)
Demo 1: /quick_check als Diagnose
/quick_check "Gibt es Speicherlecks oder sonstige Probleme in diesem C-Projekt?"
Der Judge analysiert den Code und identifiziert das leere list_free() als Speicherleck-Quelle.
Demo 2: /fix für gezieltes Nacharbeiten
/fix "Implementiere list_free() korrekt, sodass valgrind --leak-check=full sauber ist."
Coder implementiert die Funktion, committet. Kein vollständiger Judge-Loop — ideal für kleine, klar abgegrenzte Fixes.
Demo 3: /patch für Minimal-Erweiterungen
/patch "Ergänze list_search(head, value) in Header und Implementierung.
Gibt den ersten Node* mit dem gesuchten Wert zurück, oder NULL."
pi-coder wendet einen unified diff an (apply_patch-Tool), ohne den vollständigen Loop.
Manueller Build
gcc -Wall -Wextra -o ll_demo linked_list.c main.c
./ll_demo
# Mit Leak-Check:
valgrind --leak-check=full ./ll_demo