Ändere ein langlebiges portables C-Projekt, ohne die Kompatibilität zu brechen

## Prüfe vor der Änderung, welche Plattformen und Funktionsvarianten weiter laufen müssen - Behandle Portabilität, Stabilität, Robustheit und Rückwärtskompatibilität als vorrangige Entwurfsbedingungen. - Berücksichtige Kompilierungen von einer minimalen standardkonformen Konfiguration bis zu einer vollständigen grafischen Konfiguration mit optionalen Skriptschnittstellen. - Lies die übergeordnete Entwurfsrichtlinie des Repositorys, bevor du Architektur oder öffentlich sichtbares Verhalten änderst. - Unterscheide Kernquellcode, Laufzeitressourcen, Übersetzungen, Tests, Dokumentation, Teilprojekte und übernommenen Fremdcode. - Setze nicht den neuesten Compiler, das neueste Betriebssystem, den neuesten Funktionsumfang oder die neueste grafische Umgebung voraus. - Halte das Verhalten über alle unterstützten Varianten hinweg einheitlich, sofern die Änderung nicht ausdrücklich durch einen Funktionsschalter begrenzt ist. ## Baue und teste die betroffene Konfiguration ohne neue Warnungen - Verwende den dokumentierten Erstellungsweg für die aktuelle Plattform und Werkzeugkette. - Erzeuge Funktionsdeklarationen und andere abgeleitete Schnittstellen mit ihrem Generator neu, statt erzeugte Ausgaben von Hand zu bearbeiten. - Führe während der Bearbeitung die gezielte Testdatei aus und prüfe sowohl die Meldungsausgabe als auch das ausführliche Testprotokoll. - Verlange vor der Einreichung eine saubere Kompilierung ohne neue Warnungen, bestandene relevante Tests und einen Quellcodestil, der zur bearbeiteten Datei passt. - Wenn sich die Kompilierungsverfahren je nach Plattform unterscheiden, lies die Installationsanleitung dieser Plattform, statt Befehle durch Vermutung zu übertragen. - Erweitere den Testumfang, wenn gemeinsam genutzter Code, Funktionskombinationen oder Laufzeitdateien betroffen sind. ## Erzeuge generierte Dateien nur über ihren Generator neu und beachte die Zuständigen - Ermittle, welche Verzeichnisse erzeugt, von einer Fremdquelle übernommen, mit verwandten Projekten geteilt oder von einer bestimmten zuständigen Person gepflegt werden. - Ändere eine erzeugte Datei nur, wenn sich ihre Quelle ändert, und halte sachfremde Neuerzeugungen aus funktionalen Patches heraus. - Führe Änderungen an gepflegten Laufzeitressourcen durch das dokumentierte Wartungsverfahren, statt die Zuständigkeit zu umgehen. - Aktualisiere erforderliche Änderungsdaten oder Beschreibungen, wenn du ausgelieferte Laufzeit- oder Hilfedateien bearbeitest. - Ergänze für Änderungen am Kernquellcode den vom Repository verlangten Eintrag zur Patch-Nachverfolgung, sofern keine ausdrückliche Verzeichnisausnahme gilt. - Vermische niemals Fremdcode-Aktualisierungen, Erzeugungsrauschen, Übersetzungen und sachfremde Quellcodebereinigung in einem Patch. ## Nenne im Commit-Betreff das Problem, nicht die Lösung - Befolge die genaue Betreff- und Textstruktur für Patches im Repository. - Beschreibe im Betreff das Problem, nicht die Umsetzung der Lösung. - Schreibe einen vollständigen Problemsatz und einen knappen Lösungssatz mit der vorgeschriebenen Urheberangabe und Zeichensetzung. - Setze optionale Erläuterungen nach den vorgeschriebenen Problem- und Lösungsüberschriften und verwende Fließtext statt Aufzählungen, wenn das Format dies verlangt. - Kennzeichne behobene, geschlossene und verwandte Verweise entsprechend ihrer unterschiedlichen Bedeutung. - Füge die vorgeschriebene Entwicklerbestätigung ein und weise KI-Unterstützung ausschließlich über das anerkannte Mitautorenschaftsverfahren aus. ## Folge dem vorhandenen C-Stil und meide Syntax, die alte Compiler nicht kennen - Bewahre die logische Einrückung mit 4 Leerzeichen und beachte dateispezifische Regeln für Tabulatoren oder ausschließlich Leerzeichen. - Setze öffnende geschweifte Klammern bei Funktionen und Kontrollstrukturen jeweils in eine eigene Zeile. - Formatiere Funktionsdefinitionen mit Rückgabetyp und Funktionsnamen in der im Repository festgelegten Anordnung. - Richte die Position von Deklarationen nach der umgebenden Datei, statt sie nebenbei zu modernisieren. - Verwende nur die dokumentierte C-Basissprache und ihre genehmigten neueren Merkmale; führe keine Konstrukte ein, die ältere Compiler nicht unterstützen. - Führe nach Änderungen jedes dateispezifische Formatierungswerkzeug aus und prüfe dessen Unterschiede. ## Nutze die Projekttypen und gib bekannte Zeichenkettenlängen an Hilfsfunktionen weiter - Verwende die projektspezifische Typnachsilbe und vermeide Nachsilben, die Systemstandards reservieren. - Bewahre eine laufende Umstellung auf boolesche Typen: Verwende innerhalb eines Patches die örtlich etablierte boolesche Form einheitlich und vermeide Massenumstellungen. - Initialisiere lokale Variablen, wenn die erste Zuweisung nicht leicht erkennbar ist, aber füge keine redundante Initialisierung hinzu, die einen Fehler durch uninitialisiertes Lesen verbergen kann. - Verwende für Zeichenkettenliterale die Hilfsfunktion für Literallängen und bei benötigter Schreibgröße die Formatierungsfunktion, die die Länge zurückgibt. - Wenn die Länge einer Zeichenkette bereits bekannt ist, übergib sie an die längenbewusste Operation, statt die Zeichenkette erneut zu durchsuchen. - Halte jeden Zeiger auf einen Bytepuffer neben seiner `size_t`-Länge; verwende schmalere Ganzzahltypen nur, wenn eine ältere Schnittstelle sie verlangt. ## Verwalte Speicher über die Wrapper des Projekts und gib ihn bei jedem Fehler frei - Bevorzuge Projekthüllfunktionen gegenüber direkten Operationen der Standardbibliothek für Zuweisung, Freigabe, Kopieren, Verschieben, Zeichen und Leerraum. - Wähle Hüllfunktionen wegen ihrer dokumentierten Nullzeigerbehandlung, ihres Verhaltens bei Speichererschöpfung, ihrer Sicherheit bei überlappenden Bereichen, ihres Kodierungsverhaltens und ihrer Plattformkonsistenz. - Prüfe vor jeder Division ausdrücklich, dass der Divisor nicht null ist, selbst wenn eine frühere zusammengesetzte Bedingung dies scheinbar sicherstellt. - Prüfe für jede neue Speicherzuweisung die Bereinigung bei Erfolg, vorzeitiger Rückkehr und in jedem Fehlerzweig. - Führe Puffergrößen in Byte und lege das Verhalten für Kürzung, Abschluss und geschriebene Länge ausdrücklich fest. - Ersetze eine sicherere Projekthüllfunktion nicht durch einen allgemeinen Bibliotheksaufruf, nur weil dieser vertrauter ist. ## Halte Namens- und Makroregeln ein und halte Makefiles portabel - Befolge Einschränkungen für reservierte Namen, verbotene Bezeichner, Längenbegrenzungen für Funktionsnamen, Abstandsregeln und die Regel einer Anweisung pro Zeile. - Verwende das festgelegte Präfix für Funktionsmerkmale und die Konvention für großgeschriebene Makros. - Prüfe Merkmalsmakros mit dem vom Repository unterstützten Bedingungsmuster. - Halte zentrale Erstellungsdateien innerhalb des dokumentierten portablen make-Dialekts; vermeide umsetzungsspezifische Zuweisungs-, Muster-, Shell- und Bedingungserweiterungen. - Verwende die Zeichenketten- und Bytetypen des Projekts sowie die zugehörigen Makros wieder. - Lies die maßgeblichen Stilreferenzen, bevor du einen neuen Bezeichner, ein neues Makro oder eine neue Erstellungsregel einführst. ## Schreibe Laufzeitskripte, die auch in verwandten Laufzeitumgebungen und Abspaltungen laufen - Verwende für neue Dateien den aktuellen Skriptstil und berücksichtige die Kompatibilität mit verwandten Laufzeitumgebungen und Abspaltungen. - Frage vor der Einführung eines neueren Sprachkonstrukts nach, wenn die Kompatibilität unsicher ist. - Befolge in Skripttests die Benennungskonventionen für lokale Variablen. - Wiederhole einen Funktionsschalter nicht in einzelnen Tests, wenn die Datei diese Funktion bereits auf oberster Ebene begrenzt. - Hat die Datei keinen Schalter auf oberster Ebene, füge nur den Tests einen gezielten Schalter hinzu, die die optionale Funktion benötigen. - Trenne Änderungen an Laufzeitskripten von sachfremder Modernisierung der Kernsprache. ## Schreibe Regressionstests, die den gemeldeten Fehler nachstellen - Bevorzuge eine deterministische Zusicherung gegenüber einem Test, der lediglich prüft, dass das Programm nicht abstürzt. - Füge bei Darstellungsfehlern einen Bildschirmabbildvergleich hinzu und prüfe bei falschen Daten die genaue Ausgabe. - Ergänze für neues Verhalten eine umfassende Abdeckung, vorzugsweise in einer vorhandenen passenden Testdatei. - Stelle bei der Behebung eines gemeldeten Fehlers das ursprüngliche Szenario nach, nicht nur einen vereinfachten künstlichen Fall. - Verwende die Standardhilfsfunktionen für Terminalsitzungen, Bildschirmabbilder, erfolgreiches Laden von Skripten und erwartete Fehler beim Laden von Skripten. - Lege Laufzeittests für Syntax und Einrückung in ihren jeweils vorgesehenen Testsammlungen ab. ## Aktualisiere die Hilfe im selben Patch und erhalte ihr Format - Aktualisiere benutzerorientierte Dokumentation im selben Patch wie jede Änderung an einer Option oder Funktion. - Aktualisiere den Änderungsvermerk der Hilfedatei, wenn du vorhandene Dokumentation bearbeitest. - Bewahre das maßgebliche Hilfeformat für Dateiköpfe, Moduszeilen, Breite, Tabulatorausrichtung, eindeutige Marken, Querverweise, Überschriften, Codebeispiele und hervorgehobene Schreibweisen. - Verwende die sichere Neutabellierung und prüfe ihre Unterschiede; erzwinge keine umfassende Neuschreibung von Leerraum. - Halte Verweismarken im gesamten Bestand eindeutig und versehe erweiterungsspezifische Marken bei Bedarf mit einem Präfix. - Bevorzuge in neuen oder geänderten Texten geschlechtsneutrale Formulierungen, ohne unberührten Text allein zu diesem Zweck umzuschreiben. ## Prüfe zuerst die Release-Phase und lass veraltetes Verhalten erreichbar - Ermittle vor einem Umfangsvorschlag, ob sich das Projekt in einem Entwicklungszyklus oder einer Stabilisierungsphase befindet. - Beschränke während einer Stabilisierungsphase zulässige Änderungen auf eindeutige Fehlerbehebungen, Sicherheitskorrekturen, Dokumentation, Übersetzungen und Laufzeitpflege. - Führe während der Stabilisierung keine neuen Funktionen oder rückwärtsinkompatiblen Kernänderungen ein. - Bewahre freigegebenes Kernverhalten über Nebenversionen hinweg. - Halte veraltetes Verhalten über die Konfiguration erreichbar, kennzeichne es in der Dokumentation als veraltet, erlaube seine Deaktivierung zur Kompilierzeit, sofern unterstützt, und entferne es nur in einem späteren zulässigen Zyklus. - Behandle Laufzeitressourcen gemäß ihrer dokumentierten Wartungsflexibilität, ohne Kerngarantien abzuschwächen. ## Reiche Patches ein, bei denen jeder Commit allein baut und die Tests besteht - Lies die Sicherheitsrichtlinie, bevor du eine vermutete Sicherheitslücke meldest oder sicherheitsrelevanten Code änderst. - Stelle sicher, dass Commit-Format, saubere Kompilierung, relevante Tests, Regressionsabdeckung, Dokumentation und Bestätigung vollständig sind. - Beschränke den Unterschied auf das angegebene Problem: keine beiläufigen Leerraumänderungen, sachfremden Umstrukturierungen oder sachfremden erzeugten Ausgaben. - Verlange in einer mehrteiligen Patchreihe, dass jeder Commit eigenständig kompiliert und seine Tests besteht. - Hinterlasse keinen absichtlich defekten Zwischen-Commit, den ein späterer Commit repariert; führe beide zusammen. - Bestätige, dass dokumentiertes und durchgesetztes Verhalten weiterhin übereinstimmen, und beschreibe beabsichtigte Änderungen im Problem- und Lösungsvermerk. ## Ändere so wenig wie möglich und frage vor Aktionen außerhalb des Arbeitsbaums - Nimm die kleinste Änderung vor, die das Ziel erreicht, und passe dich dem umgebenden Code an, statt eine weitreichende Verbesserung aufzuzwingen. - Teile einen Patch auf, der mehrere voneinander unabhängige Probleme löst. - Wenn ein Patch nur ein Symptom behebt, benenne das tiefere Problem und die gewählte Umfangsbeschränkung. - Reproduziere einen Fehler, bevor du seine Existenz behauptest, und lies die Umsetzung, bevor du eine Aussage über das Codeverhalten triffst. - Verlasse dich nicht auf erinnerte Dateiinhalte, wenn der aktuelle Quellcode verfügbar ist. - Hole vor der Installation von Paketen, Änderungen an Dateien außerhalb des Arbeitsbaums, dem Übertragen von Zweigen oder Netzwerkzugriffen die Zustimmung des Benutzers ein.