Korrektur: die CRLF-"Reparatur" war eine erfundene Baustelle

Im Commit davor habe ich sechs Dateien von CRLF auf LF "zurueckgesetzt" und
das als Nebenbefund verbucht. Das war FALSCH.

core.autocrlf = true -> der Arbeitsbaum dieses Repos IST CRLF, git speichert
intern LF. Kontrolle an unberuehrten Dateien: core/trailing.py CR=756,
core/history.py CR=1436, server.py CR=521, tests/conftest.py CR=129 - alle
CRLF. Mein Schreib-Helfer hat also genau das erzeugt, was ein `git checkout`
erzeugt; meine "Reparatur" machte die sechs Dateien als EINZIGE inkonsistent
zum Rest. Zurueckgedreht. Kein Schaden in keiner Richtung, weil git ohnehin
normalisiert - aber es war Arbeit an einem Problem, das es nicht gab.

⚠ ZWEI ECHTE LEHREN BLEIBEN:
  (1) grep auf das Zeilenende-Zeichen meldete 0, obwohl 8.959 CR-Bytes
      drinstanden -> Zeilenenden nur ueber die BYTE-Zaehlung pruefen.
  (2) len(str) gegen os.path.getsize() zu halten vergleicht ZEICHEN mit BYTES -
      als Schrumpf-Sicherung taugt es, als Groessendifferenz nicht. Genau daran
      sah der Zuwachs zuerst nach +33 kB fuer einen 4,7-kB-Abschnitt aus.

⚠ Und ein dritter Treffer der dokumentierten Backslash-Falle: der Satz ueber
den grep-Fehlalarm enthielt ein ECHTES CR-Byte mitten im Fliesstext (CR=8975
gegen LF=8974). Gefunden nur, weil ich die beiden Zaehlungen gegeneinander
gehalten habe. Formulierung jetzt ohne Backslash.

Pipeline nach der Korrektur komplett gruen: check_nfalle, Stufe E, 97 Tests,
node --check.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Axel Hocks
2026-08-20 13:09:04 +02:00
co-authored by Claude Opus 5
parent 0966caf1b8
commit ff03ca2f43
+15
View File
@@ -8883,6 +8883,21 @@ Ticket korrekt in Slot 1 (BRK war flat, die Sperre blockt also nicht zu viel).
den der Fix adressiert. Beweis wäre dann „BRK-Slot nach Neustart
zurueckgebunden" **ohne** vorangehendes „magic-match" auf dasselbe Ticket.
⚠⚠ **NEBENBEFUND, DER KEINER WAR — und die Selbstkorrektur gehört dazu.**
Beim Nachrechnen der Dateigröße fiel auf, dass mein Schreib-Helfer sechs
Dateien von LF auf **CRLF** gedreht hatte, und ich habe sie „zurückgesetzt“.
Das war **falsch**: `core.autocrlf = true` — der Arbeitsbaum dieses Repos ist
**CRLF**, git speichert intern LF. Die Kontrolle an unberührten Dateien
(`core/trailing.py`, `server.py`, `tests/conftest.py`) zeigt überall CRLF; mein
Helfer hat also genau das erzeugt, was ein `git checkout` erzeugt. Meine
„Reparatur“ machte die sechs Dateien als Einzige **inkonsistent** zum Rest.
Zurückgedreht. **Kein Schaden in keiner Richtung**, weil git ohnehin
normalisiert — aber es war eine erfundene Baustelle.
⚠ Zwei echte Lehren bleiben: (1) ein `grep` auf das Zeilenende-Zeichen meldete **0**, obwohl 8.959
CR-Bytes drinstanden — **Zeilenenden nur über die BYTE-Zählung prüfen**;
(2) `len(str)` gegen `os.path.getsize()` zu halten vergleicht **Zeichen mit
Bytes** — als Schrumpf-Sicherung taugt es, als Größendifferenz nicht.
⚠⚠ **VIERTER Surrogat-Abbruch beim Schreiben dieses Abschnitts — und wieder
OHNE Schaden.** Ein Emoji als ZWEI getrennte Unicode-Escapes erzeugt lone
surrogates; das Öffnen im Schreibmodus kürzt die Datei aber schon VOR dem