Rust 1.99 erlaubt variadische Funktionen im C-Stil direkt in Rust
Serguey Asael Shinder1 Min. LesezeitDas Rust-Team hat am 1. Oktober Rust 1.99.0 veröffentlicht. Es ist über rustup update stable verfügbar.
Die wichtigste Neuerung schließt eine alte Lücke bei der Zusammenarbeit mit C. Rust konnte variadische Funktionen, die anderswo definiert sind – etwa libc::printf mit variabler Zahl von Argumenten –, bereits aufrufen. Ab 1.99 lassen sich solche Funktionen mit den ABIs "C" und "C-unwind" in Rust selbst definieren, mit variabler Argumentliste .... Gelesen werden die Argumente über einen Typ VaList, der auf allen Zielplattformen ABI-kompatibel zu Cs va_list ist; welche Typen sich daraus lesen lassen, ist eingeschränkt. Außerdem werden „naked“ variadische Funktionen für andere ABIs stabilisiert, die mit Inline-Assembly geschrieben werden müssen.
Eine zweite Änderung regelt die Sicherheitsanforderungen, um Größe und Ausrichtung hinter Rohzeigern abzufragen. Für Sized-Typen war das auf Stable schon möglich; drei neu stabilisierte Funktionen erweitern es auf Typen ohne feste Größe.
Außerdem ändert das Release eine Empfehlung, nicht das Verhalten. Die Dokumentation zu Box::leak rät nun von Mustern ab, die den geleakten Speicher später wieder freigeben. Laut Team wirkt solcher Code schlecht mit heutigen und möglichen künftigen Compiler-Optimierungen zusammen und ist mit der kommenden Stabilisierung eigener Allokatoren besonders problematisch. Stattdessen sollen Box::into_non_null oder Box::into_raw genutzt werden; das gilt auch für die anderen Leak-Funktionen der Standardbibliothek. Die Ankündigung betont, dass sich an der Sprachsemantik nichts ändert.
Warum das wichtig ist
Variadische Definitionen beseitigen einen Grund, in gemischten Rust- und C-Codebasen kleine C-Zwischenschichten zu behalten, etwa um einer C-Bibliothek einen Callback oder eine Logfunktion bereitzustellen. Handlungsbedarf besteht beim Hinweis zu Box::leak: Code, der eine Box leakt und sie später rekonstruiert, um den Speicher freizugeben, kompiliert weiterhin – das Team sagt aber nun, dass man ihn so nicht schreiben sollte.