Rust 1.96 väljaanne. Rusti sobivuse hindamine mikrokontrollerite vahelise tarkvara loomisel

Programmeerimiskeele Rust 1.96 väljaanne on avaldatud, mille on algatanud Mozilla projekt, kuid mida arendatakse praegu iseseisva mittetulundusühingu Rust Foundationi toetusel. Keel keskendub mäluhalduse ohutusele ja pakub vahendeid kõrge töötlusparalleelsuse saavutamiseks, samas vältides prügikoristajat ja jooksukeskkonda (runtime piirdub põhialustamise ja standardraamatukogu hooldamisega).

Rustis mäluga töötamise meetodid on suunatud vigade vältimisele pointer'itega manööverdamisel ja probleemide kaitsmisele madala taseme mälutöötlusest, nagu mälupiirkonna kasutamine pärast selle vabastamist, nullpunktide de-referentsimine, mälupiiri ületamine jne. Raamatukogude levitamiseks, ehituse tagamiseks ja sõltuvuste haldamiseks arendatakse pakihaldurit Cargo. Raamatukogude paigutamiseks toetatakse repo crates.io.

Rust tagab turvalise mälutöötluse kompilatsiooni ajal, kontrollides viiteid, jälgides objektide omandit, arvestades objektide elutsüklit (nähtavust) ja hinnates mälule juurdepääsu õigsust koodi käitamise ajal. Rust pakub ka meetmeid enamike täisarvude ületamiste vältimiseks, nõuab muutujate väärtuste algväärtustamist enne kasutamist, käsitleb vigasid paremini oma standardraamatukogus, rakendab immutamatuse (immutable) kontseptsiooni viidetes ja muutujates vaikimisi ning pakub tugevat staatilist tüüpimist loogiliste vigade minimeerimiseks.

Põhilised uuendused:

• Lisatud on range-modul, mis rakendab uusi tüüpe, mida arendatakse vananenud tüüpide Range, RangeInclusive, RangeToInclusive ja RangeFrom asendamiseks ning mis võimaldavad salvestada vahemikke Copy-struktuurides. Tüüp Range määratleb vahemikud, mis on piiratud minimaalsete ja maksimaalsete lubatud väärtustega (kuid need ei kuulu vahemikku), tüüp RangeFrom määratleb numbrid, mis algavad antud väärtusest, ja tüüp RangeInclusive - antud vahemiku väärtused koos mõlema piiri väärtustega. Tulevastes väljaannetes lisanduvad veel tüüpide RangeFull ja RangeTo, samas kui vana rakendus kantakse üle core::range::legacy::* ja süntaks „N..M“ tõlgitakse uute tüüpide variandiks.

  Uued tüübid erinevad sellest, et nende asemel, et rakendada Iterator tüüpe, rakendavad nad IntoIterator tüüpi, st nad määratlevad, kuidas tüüpi iteratsiooniks muuta, mitte ei kasuta sisseehitatud iteratoreid. Selline lähenemine võimaldab uute tüüpidega kasutada kopeerimise toimingut (tüüp Copy, mis näitab, et tüübi väärtusi saab dubleerida lihtsa kopeerimise kaudu), mis varem ei olnud võimalik sisseehitatud iteratoritega tüüpide ühilduvuse puudumise tõttu.
  Näiteks uued tüübid võimaldavad säilitada lõikepiire struktuuris, mis kopeeritakse täielikult ilma algsete ja lõppväärtuste eraldi salvestamiseta:

  use core::range::Range;

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

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

• Lisatud on makrod „assert_matches!“ ja „debug_assert_matches!“, mis kontrollivad väärtuse vastavust määratud mustrile ja lõpetavad käitamise avariiliselt, kui need ei vasta. Erinevalt „assert!(matches!(..))“ ja „debug_assert!(matches!(..))“ avaldustest, annavad uued makrod vea korral debug-infot väärtuste kohta, mis põhjustasid tõrke. Kolmandate osapoolte sama nimega makrodega ristumiste vältimiseks nõuavad uued makrod põhiteegi „core::assert_matches“ selget importimist.

  use core::assert_matches;

  fn get_random_number() -> u32 {
  4
  }

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

• WebAssembly'i sihtplatvormi ehitamisel on lõpetatud valiku „—allow-undefined” edastamine linkerile, mis lubas lingimist olemasolevate määratlemata sümbolitega, mis muudeti „env” mooduli impordiks. WebAssembly'i jaoks ehitamisel peavad kõik linkimisega seotud sümbolid nüüd vaikimisi olema määratletud. Varasema käitumise taastamiseks saab kasutada keskkonnamuutujat „RUSTFLAGS=-Clink-arg=—allow-undefined” või avaldust ‘#[link(wasm_import_module = „env”)]’ koodis.
• Stabiilsete versioonide hulka on lisatud uus komplekt API-sid, sealhulgas on stabiliseeritud meetodid ja tüüpide rakendused:
  • assert_matches!
  • debug_assert_matches!
  • From for AssertUnwindSafe
  • From for LazyCell
  • From for LazyLock
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter
• Cargo pakettihalduris on kõrvaldatud haavatavus CVE-2026-5223, mis võimaldab teise crate-paketi allika koodi ülekirjutamist kohalikus pakettide vahemikus sama hoidla kaudu sümboolsete linkide manipuleerimise kaudu crate-pakettides. Haavatavus avaldub ainult kolmandate osapoolte paketihoiustel ja ei mõjuta crates.io hoidla kasutajaid, kuna crates.io-s on sümboolsete linkide üleslaadimine keelatud.

Täiendavalt tasub märkida, et on avaldatud (PDF) analüüs, mis käsitleb Rusti keele sobivust mikrokontrollerite ja ressursipiiranguga sisseehitatud süsteemide kindlate firmware'ide arendamiseks.
Uuringu viis läbi ettevõte STMicroelectronics mitmete Euroopa ülikoolide osalusel. Kahele isoleeritud arendustiimile anti ülesanne rakendada sama firmware mikrokontrolleritele STM32U585AI, mille tuum on Arm Cortex-M33. Esimene meeskond töötas välja firmware C keeles, teine aga Rustis.

Tehtud töö testimine ei tuvastanud märgatavaid eeliseid C keele kasutamisel võrreldes Rustiga mikrokontrollerite jaoks firmware'ide arendamisel, võrreldes mälu tarbimise ja jõudlusega. Veelgi enam, Rustis kirjutatud süsteemi runtime'i kasutamine avatud projekti Ariel OS raames võimaldas saavutada Rusti projekti mälu tarbimist madalamana kui C keeles rakenduses, mis kasutas traditsioonilist stäki newlib raamatukogul põhineva firmware'i arendamiseks.

Lõppfirmware'i suurus Rusti projektis oli 84100 baiti ja C projektis 76744 baiti (10% vähem), kuid Rusti firmware'i mälutarbimine osutus oluliselt madalamaks - 24640 baiti võrreldes 42608 baitiga. Jõudluse osas, algprototüüpide testimisel, mis loodi 6 nädalaga, ületas Rusti rakendus kaks korda C rakenduse, kuid mõlemad rakendused jäid oluliselt alla arvutatud maksimaalsest jõudlusest. Pärast 4 nädalat, mis oli pühendatud optimeerimisele, saavutasid mõlemad rakendused ligikaudu sama tulemuse, mis oli lähedane arvutatud maksimumile.

Allikas: opennet.ru