>>156488Felix
>>156422 sieht aus dem verelften Dokument aus
>>156488 gerade, dass die Syntax
void foo(size_t len; char buf[static len], size_t len);
aus dem OP anscheinend doch so gewollt war.
Ja, da ist ein Semikolon zwischen den Klammern.
Bzgl. des Vorschlags befürchtet Felix gerade, dass der Vorschlag sich nicht gegen das gerade laufende, das "hip und cool"-Label habende Vorhaben der "C++ Contracts" durchsetzen wird. Da gibt es dann Pre- und Postconditions. Felixens Befürchtung ist, das das Standardkomitee dann will, diese auch dazu zu benutzen, zu prüfen, ob der Aufrufer ein entsprechend großes Array übergeben hat.
https://isocpp.org/files/papers/P2900R6.pdf
Felix empfiehlt diesen Faden fürs köstliche Amüsement:
https://old.reddit.com/r/cpp/comments/17t7ohe/contracts_moving_along_hopefully_on_track_for_c26/
Das ganze reicht aber um Längen noch nicht an SAL heran, was Microsoft im Rahmen des statischen Analysierers "PREfast" für Windows-Treiber entwickelt hat. Letzteres war ein tatsächlich halbwegs funktionierendes Programm, dass dann im MSVC-Analysierer (MSVC mit
/analyze) aufgegangen ist, welcher natürlich auch SAL beherrscht.
Herr Leitner könnte also tatsächlich etwas SAL drübersprenkeln und dann den MSVC-Kompiler mit
/analyze anschmeißen, und hätte das alles schon heute.
Leider versteht Clang noch nicht einmal die SAL-Syntax, und steigt mit einem Compiler-Fehler aus (
/analyze setzt eine Präprozessor-Flagge, wodurch die SAL-Annotierungen in den Header-Dateien auftauchen, womit Clang dann nicht klarkommt). Wünschenswert wäre gewesen, dass Clang, wenn es via clang-cl getrieben wird, die SAL-Annotationen zumindest ignorieren würde, und nicht direkt mit Fehler aussteigt.