Kleine Änderungen an einer systemnahen Bibliothek vornehmen, ohne die öffentliche API zu brechen

## Änderungen klein halten und öffentliche API und ABI nur auf Wunsch ändern Behandle eine stabile öffentliche Programmierschnittstelle und binäre Anwendungsschnittstelle als feste Einschränkungen. ### Vor der Bearbeitung - Lies vor nicht trivialen Arbeiten die Unterlagen des Projektarchivs zu Kompilierung, Prüfung, Konfiguration, Beiträgen und Veröffentlichung. - Ermittle den einen Teilsystembereich oder Belang, dem die angeforderte Änderung zugeordnet ist. - Halte dich in jeder bearbeiteten Datei an die dortigen Konventionen. - Lasse nicht zugehörige Änderungen der nutzenden Person und nicht nachverfolgte Artefakte unberührt. ### Änderungsgrenzen - Bevorzuge kleinste Unterschiede und schrittweise Folgeänderungen gegenüber umfassenden Neufassungen. - Benenne nicht zugehörigen Quelltext nicht um, ändere weder seine Reihenfolge noch Formatierung und bereinige ihn nicht. - Füge keine neue öffentliche Schnittstelle hinzu, sofern dies nicht ausdrücklich verlangt wurde. - Ändere oder entferne keine bestehende öffentliche Schnittstelle und keinen binären Vertrag, sofern dies nicht ausdrücklich verlangt wurde. - Bewahre das Verhalten optionaler Funktionen, funktionsreduzierte Kompilierungen und Funktionsschranken zur Kompilierzeit. - Ändere voreingestellte Kompilierungs- oder Funktionswerte nicht stillschweigend. Wenn scheinbar unbeholfener Quelltext an einer Kompatibilitätsgrenze liegt, gehe davon aus, dass er einen echten Grenzfall abdecken könnte, bis Prüfungen, Verlauf und umgebendes Verhalten das Gegenteil zeigen. ## Mit dem Standardablauf bauen und die Tests des geänderten Teilsystems ausführen Nutze den üblichen Ablauf des Projektarchivs zum Konfigurieren, Kompilieren und Prüfen, bevor du dich auf spezialisierte Kontrollen verlässt. ### Standardablauf 1. Konfiguriere oder rekonfiguriere das vorgesehene Kompilierungsverzeichnis. 2. Kompiliere die betroffenen Ziele. 3. Führe die für die aktuelle Phase geeignete Prüfsammlung aus. 4. Bestätige, dass die Kompilierung keine neuen Warnungen verursacht. Falls das Kompilierungsverzeichnis noch nicht vorhanden ist, verwende die Ersteinrichtung statt eines ausschließlich für die Rekonfiguration vorgesehenen Wegs. Kompiliere geänderte Ziele nach jeder wesentlichen Quelltextänderung erneut. ### Bereichsbezogene Mindestprüfungen - Führe für Umwandlungs- oder Textformungslogik die zugehörige Verhaltensprüfsammlung aus. - Führe für Reduktion, Teilmengenerzeugung oder Graphenbearbeitung die entsprechende Teilsystemprüfung aus. - Führe für Arbeiten an öffentlichen Schnittstellen die Prüfsammlung für Programmierschnittstellen aus. - Kompiliere bei Arbeiten an Befehlszeilenwerkzeugen das betreffende Werkzeug erneut und erprobe es mit einem kleinen repräsentativen Beispiel. - Ergänze oder aktualisiere bei einer Fehlerbehebung oder Parserhärtung nach Möglichkeit den nächstliegenden Regressionstest, die Testeingabe für Robustheitsprüfungen, das Prüfziel oder die erwartete Ausgabe. Bereichsbezogene Prüfungen beschleunigen die Wiederholung, ersetzen aber keine breitere Validierung, wenn gemeinsames Verhalten oder die Veröffentlichungsreife betroffen ist. ## Den Änderungsort nach Teilsystem wählen und den Projektmustern folgen Verstehe angrenzende Verantwortlichkeiten, bevor du auswählst, wo Quelltext geändert wird. ### Verantwortungsgrenzen - Trenne das Verhalten der Kernbibliothek von installierten Werkzeugen, Leistungsmessungen, Dokumentation, Sprachanbindungen und experimentellen Komponenten. - Behandle Graphenhilfen als Teil des Reduktionsablaufs, wenn sie an dessen Verhalten beteiligt sind. - Bevorzuge bei Raster-, Vektor-, Grafik- oder ähnlichen übergroßen Übersetzungseinheiten das Herauslösen klar begrenzter Hilfsfunktionen und eine Aufteilung nach Verantwortung, statt weitere Verzweigungen hinzuzufügen. - Prüfe bei einer Sprachanbindung sowohl die systemeigene Kompilierungsdefinition als auch das Paketverzeichnis der Sprache, bevor du die Verknüpfung der Kompilierung änderst. ### Bestehende Konventionen - Verwende die im Projekt etablierten Muster für Speicherzuweisung, Fehler, Sprungvorhersage, Nullobjekte, Datenstrukturen und Hilfsfunktionen. - Bevorzuge Projektabstraktionen gegenüber unmittelbaren Plattformoperationen, wenn die Abstraktionen Portabilitäts- oder Sicherheitsverhalten enthalten. - Führe keine fremde Datenstrukturbibliothek in den Kernquelltext ein, wenn das Projekt bereits etablierte Datenstrukturen und Hilfsfunktionen besitzt. - Ergänze Dokumentation für öffentliche Schnittstellen an der im Projektarchiv üblichen Stelle im Quelltext oder in den Unterlagen. Fasse doppelte Analyse-, Zwischenspeicher- oder Hilfslogik zusammen, sobald sich die Doppelung ausbreitet, aber mache aus einer begrenzten Fehlerbehebung keine nicht zugehörige Architekturneufassung. ## Bei Speicherfehlern und feindlichen Eingaben auf allen Plattformen sicher scheitern Behandle Zuweisungsfehler, feindselige Eingaben, unterschiedliche Kompilierer und funktionsreduzierte Kompilierungen als normale Teile des unterstützten Umfangs. ### Sicherheit von Zuweisung und Parser - Folge den bestehenden Mustern für Zuweisung und Fehlerbehandlung, damit neuer Quelltext bei Speicherdruck sicher scheitert. - Untersuche bestehende Parserschranken und die Infrastruktur für Robustheitsprüfungen, bevor du die Eingabeverarbeitung härtest. - Bei einem künstlich ausgelösten Zuweisungsfehler besteht das kleinste akzeptable Ergebnis darin, dass weder Absturz noch Bereichsüberschreitung oder Speicherbeschädigung auftreten. - Bei experimentellen Komponenten ist unter Speicherdruck ein bestmögliches frühes Scheitern akzeptabel. - Füge keine komplexe Rücksetzlogik ausschließlich zum Erhalt von Teilergebnissen nach einem Zuweisungsfehler hinzu, sofern der Vertrag der Komponente dies nicht verlangt. ### Portabilität - Behandle Rückschritte bei Kompilierern, Betriebssystemen, Architekturbreiten, Kreuzkompilierung und funktionsreduzierten Kompilierungen als echte Fehler. - Prüfe Annahmen über alle vom Projekt unterstützten Werkzeugketten und Ganzzahlbreiten hinweg. - Führe Funktionsschranken zur Kompilierzeit und Ausweichwege tatsächlich aus. - Prüfe beim Vereinfachen systemnahen Quelltexts, ob die ursprüngliche Komplexität Ausrichtung, Überlauf, Lebensdauer, Speicheraliasierung oder plattformspezifisches Verhalten behandelte. Bevorzuge einen reproduzierbaren Regressionstest gegenüber einer reinen Fehlerbehebung, die den ursprünglichen Fehler nicht nachweisen kann. ## Erzeugte Tabellen über den Generator neu erzeugen, statt sie von Hand zu ändern Halte jede Erstellungsbeschreibung und jedes erzeugte Ergebnis mit der Quelltextänderung synchron. ### Änderungen am Erstellungssystem - Aktualisiere Optionen, Konfigurationszusammenfassungen, installierte Werkzeuge, Prüfungen und abhängige Ziele gemeinsam. - Untersuche bei Auswirkungen auf Paketierung oder Kreuzkompilierung jedes unterstützte Erstellungssystem, statt nur das vorrangige zu ändern. - Bewahre voreingestellte Optionswerte, sofern die Aufgabe nicht ausdrücklich eine Änderung verlangt. - Prüfe bei betroffenen optionalen Funktionen sowohl die aktivierte als auch die deaktivierte Form. ### Erzeugte Daten - Ändere den Generator, die Quelldaten oder den Ablauf der Erstellungsautomatisierung und erzeuge anschließend die Ergebnisse neu. - Bearbeite erzeugte Tabellen oder Verzeichnisse nicht von Hand, sofern die Aufgabe dies nicht ausdrücklich verlangt. - Gehe nicht davon aus, dass erzeugte Ergebnisse, örtliche Prüfdaten, Schriftarten oder nicht nachverfolgte Artefakte entbehrlich sind. - Prüfe neu erzeugte Unterschiede auf unerwartete Breite oder nicht deterministische Änderungen. Wenn eine Generatoränderung öffentliche Daten oder Prüferwartungen betrifft, aktualisiere die zugehörigen Prüfungen und Unterlagen innerhalb derselben begrenzten Änderung. ## Öffentliche API nur auf Wunsch hinzufügen, mit Versionsmarke und Dokumentation Behandle nutzersichtbares Verhalten als abgestimmte Änderung von Quelltext, Dokumentation, Versionsführung und Kompilierungsverknüpfung. ### Freigabegrenze für öffentliche Schnittstellen - Halte öffentliche Deklarationen in den vorgesehenen öffentlichen Kopfdateien oder Modulen, nicht in internen Implementierungsdateien. - Füge neue öffentliche Schnittstellen nur hinzu, wenn die Anfrage dies ausdrücklich erlaubt. - Ergänze bei einer erlaubten neuen Schnittstelle die vorgeschriebene Versionsmarkierung und den Veröffentlichungshinweis des Projektarchivs. - Aktualisiere erzeugte Abschnittsverzeichnisse, Dokumentationsverzeichnisse oder Referenzlisten über den genehmigten Ablauf. - Bewahre Binäranordnung, Symbolsichtbarkeit, Aufrufkonventionen und Quelltextkompatibilität, sofern eine inkompatible Änderung nicht ausdrücklich genehmigt wurde. ### Nutzersichtbares Verhalten - Aktualisiere zugehörige Unterlagen, wenn eine Funktion über eine Bibliothek oder ein installiertes Werkzeug sichtbar wird. - Halte Installation und Kompilierungsverknüpfung mit neu offengelegtem Verhalten synchron. - Lege die Dokumentation öffentlicher Schnittstellen und erzeugte Verzeichnisse dort ab, wo es die örtliche Praxis verlangt. - Deaktiviere eine fehlgeschlagene Prüfung nicht nur, um einen erfolgreichen Lauf zu erhalten; dokumentiere eine begründete Ausnahme und ihre Auswirkungen. ## Zuerst die Ursache finden und committen, ohne zu pushen Belege Ursache und Ergebnis, bevor du eine Änderung als abgeschlossen darstellst. ### Arbeitsweise 1. Stelle den Fehler nach, wenn dies praktisch möglich ist. 2. Verstehe die Ursache, bevor du die Fehlerbehebung schreibst. 3. Frage nach, statt zu raten, wenn eine wesentliche Mehrdeutigkeit verbleibt. 4. Untersuche den Verlauf, bevor du ungewöhnlich komplex erscheinenden Quelltext vereinfachst. 5. Ergänze oder aktualisiere die nächstliegende Regressionsabdeckung. 6. Validiere das geänderte Teilsystem, betroffene Konfigurationen und das breitere Verhalten. ### Regeln für Änderungssätze - Führe die vollständige Prüfsammlung aus, bevor du Quelltext, Kompilierungslogik, erzeugte Ergebnisse oder Prüfeingaben in einem Änderungssatz festschreibst. - Reine Dokumentations- oder fortlaufende Integrationsänderungen dürfen die vollständigen Prüfungen nur auslassen, wenn sie diese Bereiche nicht betreffen können; melde die Auslassung. - Beschränke jeden Änderungssatz auf ein Problem oder einen Belang. - Übertrage niemals an das entfernte Projektarchiv; überlasse die Übertragung der befugten Person. - Verwende das Teilsystempräfix, die Zuordnungszeilen am Nachrichtenende und die Nachrichtenkonventionen des Projektarchivs. - Verwende für eine mehrzeilige Änderungsnachricht eine Datei oder eine editorgestützte Eingabe statt maskierter Zeilenumbruchfolgen. - Beschreibe Ursache, Behebung und Prüfungen nur, wenn die tatsächlich ausgeführte Arbeit sie belegt. Melde bei der Übergabe den geänderten Umfang, ausgeführte Prüfungen, Warnungen, nicht unterstützte Konfigurationen, ungelöste Risiken und jede nicht durchgeführte Validierung.