Utgåvan av Rust 1.96. Bedömning av Rusts lämplighet för att skapa firmware för mikrokontroller.

Utgåvan av programmeringsspråket Rust 1.96 har publicerats, som ursprungligen utvecklades av Mozilla men numera utvecklas under ledning av den oberoende ideella organisationen Rust Foundation. Språket fokuserar på säker hantering av minne och tillhandahåller medel för att uppnå hög parallellism i uppgiftsexekvering, utan att använda en skräpares samlare och runtime (runtime begränsas till grundläggande initiell och underhåll av standardbiblioteket).

Minneshanteringsmetoderna i Rust syftar till att eliminera fel vid hantering av pekare och skydda mot problem som uppstår från låg nivå minneshantering, såsom att referera till minnesområden efter att de har frigjorts, dereferensiering av nullpekare, buffertöverskridningar, etc. För spridning av bibliotek, byggnation och hantering av beroenden utvecklas paketchefen Cargo. För att lagra bibliotek stöds ett repository på crates.io.

Säker minneshantering säkerställs i Rust under kompilering genom att kontrollera referenser, spåra ägandeskap över objekt, ta hänsyn till livslängden av objekt (synlighet) och utvärdera korrekt minnesåtkomst under körning av koden. Rust erbjuder också verktyg för att skydda mot heltalsöverflöden, kräver obligatorisk initialisering av variabelvärden innan de används, hanterar fel bättre i standardbiblioteket, tillämpar konceptet av oföränderliga (immutable) referenser och variabler som standard och erbjuder stark statisk typning för att minimera logiska fel.

Huvudsakliga nyheter:

• Modulen range har lagts till med implementeringen av nya typer som utvecklas för att ersätta de utdaterade typerna Range, RangeInclusive, RangeToInclusive och RangeFrom, och som möjliggör lagring av intervall i Copy-strukturer. Typen Range definierar intervall begränsade av ett minimalt och maximalt tillåtet värde (men inklusive inte det), typen RangeFrom definierar siffror som börjar från ett angivet värde, medan typen RangeInclusive inkluderar värdena i det angivna intervallet med båda gränserna. I framtida utgåvor kommer ytterligare typer som RangeFull och RangeTo att introduceras, där den gamla implementationen flyttas till core::range::legacy::* och syntaxen 'N..M' kommer att översättas till de nya typerna.

  De nya typerna skiljer sig åt genom att de implementerar typtraitet IntoIterator istället för Iterator, det vill säga, istället för den inbyggda iteratorn definierar de hur man konverterar typen till en iterator. Denna metod tillåter användning av kopieringsoperationen (typtraitet Copy, vilket visar att värden av typen kan dupliceras genom enkel kopiering), vilket tidigare var otillgängligt på grund av inkompatibilitet med typer med inbyggda iteratorer.
  Till exempel ger de nya typerna möjlighet att spara gränserna för en skiva i en struktur som helt kopieras utan separat lagring av start- och slutvärden:

  use core::range::Range;

  #[derive(Clone, Copy)]
  pub struct Span(Range);

  impl Span {
  pub fn of(self, s: &str) -> &str {
  &s[self.0]
  }
  }

• Makron 'assert_matches!' och 'debug_assert_matches!' har lagts till, som kontrollerar om ett värde matchar ett angivet mönster och avslutar exekveringen om det finns en avvikelse. De nya makron skiljer sig i att de ger ut debug-information med värdena som orsakade felet, till skillnad från uttrycken 'assert!(matches!(..))' och 'debug_assert!(matches!(..))'. För att undvika kollisioner med tredjepartsmakron som levereras med liknande namn, kräver de nya makron en explicit import av biblioteket 'core::assert_matches'.

  use core::assert_matches;

  fn get_random_number() -> u32 {
  4
  }

  fn main() {
  assert_matches!(get_random_number(), 1..=6);
  }

• Vid sammansättning för målplattformen WebAssembly har överföringen av länkaralternativet "—allow-undefined" avbrutits, vilket tillät länkning vid förekomsten av odefinierade symboler, som omvandlades till import från modulen "env". Vid sammansättning för WebAssembly måste nu alla länkade symboler per standard vara definierade. För att återfå det gamla beteendet kan miljövariabeln "RUSTFLAGS=-Clink-arg=—allow-undefined" eller uttrycket ‘#[link(wasm_import_module = "env")]’ i koden användas.
• En ny uppsättning API har blivit stabiliserad, inklusive stabilisering av metoder och implementeringar av traits:
  • assert_matches!
  • debug_assert_matches!
  • From för AssertUnwindSafe
  • From för LazyCell
  • From för LazyLock
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter
• I paketförvaltaren Cargo har sårbarheten CVE-2026-5223 åtgärdats, vilken kan användas för att skriva över källkoden för ett annat crate-paket i den lokala paketcachen från samma förvar genom manipulation med symboliska länkar inuti crate-paketet. Sårbarheten uppträder endast vid arbete med externa paketförvar och berör inte användare av förvaret crates.io, eftersom uppladdning av paket med symboliska länkar är förbjudet på crates.io.

Ytterligare kan man nämna publiceringen (PDF) av resultaten från en analys av Rust-språkets lämplighet för utveckling av firmware för mikrokontroller och inbyggda system med begränsade resurser.
Studien genomfördes av STMicroelectronics i samarbete med flera europeiska universitet. Två isolerade utvecklarteam fick i uppdrag att implementera samma firmware för STM32U585AI mikrokontroller med Arm Cortex-M33-kärna. Det första teamet skapade firmware i C, medan det andra i Rust.

Testningen av det utförda arbetet visade inga påtagliga fördelar med att använda C istället för Rust vid utveckling av firmware för mikrokontroller när man jämförde minnesanvändning och prestanda. Dessutom gjorde användningen av den Rust-baserade system runtime från det öppna projektet Ariel OS att minnesanvändningen i Rust-projektet var lägre än i C-implementeringen som använde en traditionell stack för firmwareutveckling baserad på newlib-biblioteket.

Den resulterande firmware-storleken var 84100 byte i projektet på Rust och 76744 byte i projektet på C (10% mindre), men minnesanvändningen i firmware på Rust visade sig vara betydligt lägre — 24640 byte mot 42608 byte. När det kommer till prestanda, vid testning av de första prototyperna som utvecklades under 6 veckor, överträffade implementationen på Rust den på C med två gånger, men båda implementationerna låg betydligt under den beräknade maximala prestandan. Efter 4 veckors optimering nådde båda implementationerna ungefär samma resultat, nära det beräknade maximum.

Källa: opennet.ru