pi_coder/examples/c-linkedlist
2026-05-29 19:06:36 +02:00
..
linked_list.c feat: Demo-Examples (Python/Rust/Go/C) mit Protokoll-Templates und Restore-Skript 2026-05-29 19:06:36 +02:00
linked_list.h feat: Demo-Examples (Python/Rust/Go/C) mit Protokoll-Templates und Restore-Skript 2026-05-29 19:06:36 +02:00
main.c feat: Demo-Examples (Python/Rust/Go/C) mit Protokoll-Templates und Restore-Skript 2026-05-29 19:06:36 +02:00
PROTOKOLL.md feat: Demo-Examples (Python/Rust/Go/C) mit Protokoll-Templates und Restore-Skript 2026-05-29 19:06:36 +02:00
README.md feat: Demo-Examples (Python/Rust/Go/C) mit Protokoll-Templates und Restore-Skript 2026-05-29 19:06:36 +02:00

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 15, 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