In hardwarenahen Systempatches echte Fehler finden statt Stilkleinigkeiten

## Mögliche Fehler auch bei Unsicherheit melden, Stilfragen nur bei hoher Sicherheit Behandle Korrektheitsfehler als die wertvollsten Feststellungen. Melde einen plausiblen Korrektheitsfehler ab einer Konfidenz von 50 Prozent und benenne die Unsicherheit, wenn die Belege unvollständig sind. Ein möglicher Zugriff nach Freigabe, ein Ressourcenleck, ein Datenrennen oder eine Grenzverletzung ist auch dann erwähnenswert, wenn weitere Bestätigung erforderlich ist. Wende auf Feststellungen zu Stil, Formatierung und Verfahren einen anderen Schwellenwert an: - Melde sie nur bei einer Konfidenz von mehr als 80 Prozent. - Lasse alles weg, was du abschließend als korrekt, vertretbar oder harmlos beurteilst. - Äußere niemals eine Sorge, um ihr dann in derselben Feststellung zu widersprechen. - Beschränke jeden Kommentar nach Möglichkeit auf einen handlungsorientierten Satz. Prüfe jede Änderung anhand ihres eigenen Verhaltens. Leite aus einem isolierten Änderungsvergleich weder die Reihenfolge einer Änderungsserie noch änderungsübergreifende Kompilierungsabhängigkeiten oder die Umstände des Beitragenden ab. Lasse in einer Serie fehlerfreie Änderungen weg, statt sie als problemfrei zusammenzufassen. ## Speicherzuweisungen und Fehlerpfade auf Lecks und Fehlgebrauch verfolgen Verfolge für jede Speicherzuweisung, jedes geöffnete Zugriffsobjekt, jede erworbene Sperre und jedes teilweise initialisierte Objekt alle späteren Verzweigungen. Prüfe frühe Rückgaben und Bereinigungsmarken auf lückenlose Freigaben, richtige Reihenfolge und erhaltene Fehlercodes. Räume folgenden Punkten Vorrang ein: - Zugriff nach Freigabe, doppelte Freigabe, Nullzeigerdereferenzierung und erreichbare Lesezugriffe auf nicht initialisierte Werte. - Lecks von Speicher, Deskriptoren, Netzwerkverbindungen, Sperren oder teilweise aufgebauten Mitgliedern. - Fehlende Fehlerprüfungen bei Vorgängen, die tatsächlich fehlschlagen können. - Falsche Rückgabewerte, verworfener Fehlerzustand, umgekehrte Bedingungen und um eins verschobene Grenzen. - Ein Wert, der vor seinem ersten Lesezugriff bedingungslos überschrieben wird. - Wiederverwendung desselben Schleifenzählers in verschachtelten Schleifen. - Zählerfortschreibung, die einen Messwert zuweist, statt ihn zu addieren. Unterscheide fortlaufende Zähler von Momentanwerten und Erstzuweisungen. Beanstande einen ungeprüften Rückgabewert nicht allein deshalb, weil eine Funktion einen ganzzahligen Rückgabetyp hat, wenn die unterstützte Plattform dokumentiert, dass der Aufruf bei gültigen Argumenten nicht fehlschlagen kann. ## Ganzzahlbreiten und Paketgrößen prüfen Prüfe arithmetische Vorgänge anhand der Operandenbreite und nicht nur anhand der Zielbreite: - Erweitere vor der Multiplikation mindestens einen Operanden, wenn das Ergebnis einen breiteren Typ benötigt. - Verwende vor dem Verschieben in eine breite Bitmaske ein Literal oder einen Operanden, der so breit wie das Ziel ist. - Erweitere schmale vorzeichenlose Werte vor einem Verschiebevorgang, der in Zeigerarithmetik oder für ein breites Ergebnis verwendet wird. - Verändere Verschiebevorgänge mit schmalem Ergebnis nicht, wenn ihr gesamter Wertebereich hineinpasst und kein breiterer Kontext beteiligt ist. - Begrenze jede durch Eingaben eines Gasts, Pakets, Geräts oder der API gesteuerte Verkettungs- oder Indexdurchquerung. Beachte beim stapelweisen Freigeben von Paket- oder Deskriptorobjekten die Eigentumsverhältnisse. Ein Massenvorgang, der einen einzigen Zuweiser oder Speicherpool voraussetzt, ist für Felder unsicher, deren Elemente aus unterschiedlichen Quellen stammen können; verwende einen speicherpoolbewussten Freigabepfad, sofern der Vertrag des Schnellpfads nicht einheitliches Eigentum belegt. Halte die Nutzdatengröße des Protokolls von der vollständigen Rahmengröße getrennt. Leite den Rahmenzusatz aus den Gerätefähigkeiten statt aus einer allgemeingültigen Konstante ab und lies nach der Einrichtung die maßgebliche aktuelle Konfiguration statt eines veralteten Anforderungsfelds. Wenn ein Rahmen nicht in einen einzelnen Empfangspuffer passt, muss die Umsetzung einen unterstützten Mehrsegmentpfad aktivieren oder die Konfiguration ablehnen. Prüfe dies während der Erstkonfiguration, der Warteschlangeneinrichtung und bei Größenänderungen zur Laufzeit erneut und wähle die Empfangsfunktion sowohl anhand des konfigurierten Modus als auch anhand des tatsächlichen Größenbedarfs aus. ## Prüfen, ob gemeinsame Daten Atomics oder Locks statt volatile nutzen Akzeptiere `volatile` nicht als Synchronisierung zwischen Ausführungsfäden. Gemeinsam genutzter veränderlicher Zustand erfordert atomare Vorgänge oder eine geeignete Sperre; `volatile` schränkt nur den Compilerzugriff ein und liefert weder Atomizität noch Speicherreihenfolge. Wähle die schwächste Reihenfolge, die noch korrekt ist: - Lockere Reihenfolge für unabhängige Statistiken und Merker, die keine zugehörigen Daten veröffentlichen. - Speicherungen mit Freigabesemantik und Ladevorgänge mit Erwerbssemantik für Veröffentlichungs- und Verbrauchsbeziehungen. - Erwerbs- und Freigabereihenfolge für Lesen-Ändern-Schreiben-Vorgänge, die Zustand sowohl verbrauchen als auch veröffentlichen. - Sequenzielle Konsistenz nur dann, wenn unabhängige atomare Werte eine einzige globale Reihenfolge erfordern. Bevorzuge die Reihenfolge am atomaren Vorgang gegenüber einer eigenständigen Speicherbarriere. Eine Speicherbarriere ist nur angemessen, wenn sie eine größere Gruppe nicht atomarer Zugriffe ordnen muss. Erlaube `volatile` für Hardwareregister und andere tatsächlich gerätebezogene Zugriffe. Verlange für Mutexe, Bedingungen, Barrieren oder Lese-Schreib-Sperren im gemeinsam genutzten Speicher zwischen Prozessen eine prozessübergreifende Initialisierung; verlange sie nicht für prozessprivaten Speicher. Bevorzuge für gemeinsamen Speicher entworfene Synchronisierungsprimitive, wenn deren Warteverhalten zum Anwendungsfall passt. ## Kryptografie nur prüfen, wenn der Patch Schlüssel oder Geheimnisse behandelt Wende kryptografische Prüfungen nur an, wenn die Änderung Schlüssel, Einmalwerte, Authentifizierungsmaterial oder Quelltext eines Sicherheitsprotokolls verarbeitet. - Vergleiche von Angreifern beeinflussbare Authentifizierungskennzeichen, Prüfsummen, MACs oder Integritätswerte mit einem Gleichheitsprimitiv konstanter Laufzeit. - Bewahre beim Ersetzen eines gewöhnlichen Bytevergleichs dessen Gleichheitssemantik. - Lösche Schlüssel, erweiterte Schlüsselpläne, Sitzungsgeheimnisse und ähnliches Material vor der Freigabe mit einem Vorgang, der nicht wegoptimiert werden kann. - Erzeuge Schlüssel, Initialisierungsvektoren und Einmalwerte mit einer kryptografisch sicheren Zufallsquelle. Beanstande keine gewöhnlichen Vergleiche von Algorithmuskennungen, Längen, Fähigkeiten oder Nachschlageschlüsseln. Behaupte aufgrund einer statischen Änderung keine Wiederverwendung eines Einmalwerts, wenn die Wiederverwendung eine Laufzeiteigenschaft ist, die sich aus dem Änderungsvergleich nicht belegen lässt. ## Bibliotheks-APIs einfach halten und inkompatible ABI-Änderungen versionieren Entwirf eine wiederverwendbare Bibliothek als compilerähnlichen Dienst: Erzeuge ein Zugriffsobjekt, liefere Eingaben, empfange strukturierte Ausgaben und überlasse dem Aufrufer die Entscheidung über das weitere Vorgehen. Vermeide Einzelinstanzzustand und Rückruftabellen, die den Aufrufer zwingen, zum Hintergrundsystem der Bibliothek zu werden. Für öffentliche Rückruffunktionen und Datenmodelle: - Bevorzuge einen einzelnen Rückrufparameter gegenüber einer großen Vorgangstabelle. - Behandle mehr als fünf Rückruffunktionen als Hinweis auf eine Neugestaltung und mehr als zwanzig als API-Entwurfsfehler. - Dokumentiere Eigentum, Lebensdauer, Rückgabewerte und Fehlerverhalten der Rückruffunktionen. - Verwende für Vorgänge, die fehlschlagen können, keine Rückruffunktionen ohne Rückgabewert. - Bevorzuge erweiterbare markierte Datensätze gegenüber einer wachsenden Aufzählung zusammen mit einem wachsenden Variantenverbund. Alles, was als Headerdatei installiert wird, ist unabhängig von seiner Kennzeichnung eine öffentliche API. Lege Eigentum und Lebensdauer von Puffern ausdrücklich fest, insbesondere bei internem statischem Speicher. Neuer Quelltext darf keine veralteten Schnittstellen einführen. Die Kennzeichnung als veraltet setzt voraus, dass es innerhalb des Quellbaums keine verbleibenden Nutzer gibt, und benötigt Veröffentlichungsdokumentation, einen Migrationspfad sowie eine für den Compiler sichtbare Anmerkung. Platziere öffentliche, experimentelle und interne Anmerkungen genau dort, wo die Werkzeugkette sie erwartet, exportiere Symbole aus Quelldefinitionen und verwende ABI-Versionierung für inkompatible Änderungen stabiler Signaturen. Verlange niemals manuelle Änderungen an generierten Symbolzuordnungsdateien. ## Mechanischen Stil den Werkzeugen überlassen und prüfen, was sie nicht erkennen Überlasse mechanische Ersetzungen Formatierungsprogrammen, Werkzeugen für semantische Änderungen und den Prüfskripten des Repositorys. Nutze menschliche oder KI-gestützte Prüfung für Fälle, die diese Werkzeuge nicht verstehen können. Prüfe die festgelegten Projektregeln für Einrückung, Zeilenenden, Gruppen eingebundener Dateien, Klammern, Funktionsanordnung, Bezeichner und Namensraumpräfixe. Verlange eindeutige Präfixe für extern sichtbare Bibliotheks- oder Treibersymbole, um Kollisionen beim statischen Binden zu vermeiden. Verwende inklusive Terminologie. Bevorzuge echte boolesche Typen für Wahr-oder-falsch-Zustände, behalte jedoch Ganzzahlen für Fehlercodes oder mehrstufige Werte bei und vermeide sachfremde Typänderungen in etabliertem Quelltext. Halte Funktionssprungtabellen zur Kompilierzeit konstant, sofern sie nicht durch Laufzeitregistrierung oder Fähigkeitserkennung verändert werden. Stimme Zuweisungs- und Kopierprimitive auf den Datenpfad ab: - Verwende gewöhnliche Zuweisung im Haufenspeicher für allgemeine Steuerdaten. - Verwende für DMA, Warteschlangen oder prozessübergreifende Daten eine gerätesichtbare, NUMA-bewusste und mit Nullen initialisierte Zuweisung. - Verwende optimiertes Massenkopieren nur dort, wo der Schnellpfad davon profitiert und sein Vertrag erfüllt ist. Kommentare sollen Einschränkungen und Absichten erläutern, statt den Quelltext nachzuerzählen. ## Tests und Dokumentation mit jeder Codeänderung mitpflegen Jeder Änderungssatz soll eigenständig erstellbar sein, aber eine Person, die nur eine Änderung prüft, darf nicht über die Reihenfolge der Serie spekulieren. Prüfe mit den vom Projekt unterstützten Compilern, Zielen, Optionen und Erstellungsskripten. Füge gezielte Tests für neues Verhalten und öffentliche APIs hinzu. Verwende die Prüfzusicherungen und das Ausführungswerkzeug für Testsammlungen des Repositorys, dokumentiere Umgebungsanforderungen genau und stelle für eine neue gerätebezogene API mindestens eine Umsetzung bereit. Aktualisiere Quelltext und Dokumentation atomar: - Dokumentiere öffentliche APIs und wichtige benutzersichtbare Änderungen. - Halte Funktionalitätsmatrizen und Vorgangsdokumentation mit der Umsetzung im Einklang. - Aktualisiere nur die Hinweise der aktuellen Version für öffentliche APIs, neue Treiber oder wesentliche Verhaltensänderungen. - Verlange keine Versionshinweise für reine Teständerungen oder interne Umsetzungsänderungen. - Bevorzuge Definitionslisten in strukturierter Dokumentation, wenn jeder Eintrag aus einem Begriff mit ausführlicher Beschreibung besteht; behalte einfache Listen für kurze Einträge und Verfahren bei. Wende das im Repository verwendete Formatierungsprogramm für die Sprache des Erstellungssystems und dessen Sortierregeln an. Prüfe Python mit dem vorgesehenen Formatierungsprogramm und der Zeilenlängenrichtlinie. ## Regeln für stabile Zweige nur bei stabilem Ziel anwenden Verwende strenge Regeln für stabile Veröffentlichungen nur, wenn der Zielzweig oder die Zielversion ausdrücklich als stabil bezeichnet ist. Erlaube dann ausschließlich Fehlerkorrekturen: keine neuen Funktionalitäten, öffentlichen APIs, ABI-Änderungen, Symbole, Konfigurationsoptionen oder sachfremden Umstrukturierungen. Verlange, dass eine Rückportierung auf die ursprüngliche Korrektur verweist und der Benachrichtigungskonvention des Projekts für stabile Versionen folgt. Behandle eine umfangreiche Bereinigung rund um eine kleine Korrektur als Warnsignal, weil sie das Risiko der Rückportierung erhöht. Ist keine Version angegeben, gehe vom Hauptentwicklungszweig aus, in dem neue Funktionalitäten und APIs zulässig sein können. Wende niemals nur deshalb Verbote für stabile Versionen an, weil das Repository auch stabile Zweige pflegt. ## Konkrete Korrekturen nennen und Feststellungen vor dem Absenden zweimal prüfen Ordne bestätigte Fehler bei Speichersicherheit, Synchronisierung, Grenzen, Bereinigung, Kryptografie, ABI und Kompilierung als Fehler ein. Verwende Warnungen für fehlende Tests oder Dokumentation, ungeeignete API-Formen, neu hinzugefügte veraltete Elemente, Fehlgebrauch der Speicherzuweisung und mit hoher Konfidenz erkannte Wartbarkeitsprobleme. Melde nicht: - Fehlstellen in generierten Symbolzuordnungsdateien, Urheberrechtsangaben oder Formatierung von Änderungssätzen, die bereits in die Zuständigkeit von Prüfwerkzeugen fallen. - Korrekte Verwendung von Hardware-`volatile`, prozessprivaten Sperren, Mehrsegmentempfang oder aktuellen Testmakros. - Vage Aufforderungen, etwas ohne einen Beleg für einen Fehler zu prüfen. - Fehlerfreie Änderungen, spekulative änderungsübergreifende Fehler oder Beobachtungen ohne Korrekturmaßnahme. Nenne bei jedem echten Problem zuerst das Problem, erläutere die Auswirkung nur, wenn sie nicht offensichtlich ist, und gib eine konkrete Korrektur oder eine Richtung für die Quelltextänderung an. Führe vor der Abgabe zwei getrennte Prüfgänge durch: 1. Korrektheitsprüfung: Nimm plausible Korrektheitsfeststellungen wieder auf, die ohne Beleg verworfen wurden, und bestätige, dass Ressourcenpfade, Lebensdauer, Grenzen und Fehlerweitergabe verfolgt wurden. 2. Fehlalarmprüfung: Entferne jeden Stil- oder Verfahrenspunkt, den die Analyse selbst als vertretbar, korrekt oder harmlos beurteilt hat. Eine nach diesen Prüfgängen leere Feststellungsliste ist zulässig. Erfinde keine Kommentare, nur um sie zu füllen.