Avalikustatud on universaalsete programmeerimiskeelte Rust 1.81 versioon, mille arendamine algas Mozilla projekti all, kuid praegu jätkab seda sõltumatu mittetulundusühing Rust Foundation. Keele peamine fookus on mäluhalduse turvalisus, pakkudes vahendeid ülesannete kõrge paralleelset täitmist, ilma et oleks vaja prügikogumissüsteemi ja runtime'i (runtime koosneb põhiinisialiseerimisest ja standardteegi toetamisest).
Mäluga töötamise meetodid Rust'is vabastavad arendajad pointerite manipulatsiooni vigadest ja kaitsevad neid probleemide eest, mis tulenevad madala taseme mälu haldamisest, nagu mälualale pärast selle vabastamist juurdepääs, null-pointerite dereferentseerimine, puhverserveri piiridest väljumine jne. Raamatukogude levitamiseks, kokkupaneku tagamiseks ja sõltuvuste haldamiseks arendatakse paketihaldurit Cargo. Raamatukogude majutamiseks toetatakse repoturite crates.io.
Mäluhügieen Rust'is tagatakse kompileerimise ajal viidete kontrollimise, objektide omandi jälgimise, objektide eluaja (vaateala) arvestamise ja mälule juurdepääsu korrektuse hindamise kaudu koodi täitmise ajal. Rust pakub ka vahendeid täisarvude ülevoolude vältimiseks, nõuab muutujate väärtuste kohustuslikku initsialiseerimist enne kasutamist, käsitleb vigu paremini standardraamatukogus, rakendab muutumatuse (immutable) mõistet viidete ja muutujate jaoks vaikimisi ning pakub tugevat staatilist tüüpimist loogiliste vigade vähendamiseks.
Peamised uuendused:
- Stabiliseeritud on core::error::Error tüüpi, mis määratleb tõrgete kirjelduste väljundi. See muudatus võimaldab kasutada ühtset Error tüüpi erinevates teekides, sõltumata keskkonnast, sealhulgas teekides, mis ei ole seotud standardteegiga ja kasutavad atribuudiga «#![no_std]».
- Standardteegis on stabiilsed ja ebastabiilsed sorteerimisfunktsioonid viidud üle uutele algoritmidele, mis demonstreerivad kõrgemat töökäiku ja lühemaid kompileerimisaegu. Uute sorteerimisalgoritmide rakenduses on tagatud tagasiside kehvasti määratletud Ord tüüpide määramisel ja vale korral antakse välja viga (panic), mitte ei rühmitata andmeid suvaliselt.
- Linteris on rakendatud uus kontrolliastme «expect» («#[expect(lint)]»), mis võimaldab kindlaks teha, kas kontroll on läbitud, ja väljastada hoiatuse, kui kontrolli ei ole läbitud (kas rakenduse vea või kontrolli keelamise tõttu). Näiteks, kui koodibaasi muudetakse undisclosed_unsafe_blocks kontrollima Clippy abil, saab märkida «#[expect(clippy::undocumented_unsafe_blocks)]», et kinnitada, et kõiki unsafe-blokke dokumenteeritakse ülemineku protsessis. Clippy's on samuti rakendatud kontrolle clippy::allow_attributes ja clippy::allow_attributes_without_reason, mis lihtsustavad atribuutide «#[allow]» muutmist «#[expect(lint)]» lähenemiseks.
- Antud on võimalus dokumenteerida kontrollide (lint) tasemete asendamise põhjust, pakkudes uutele arendajatele teavet selle kohta, miks teatud kontroll on lisatud, ja seda väljendatakse kompilatsiooniteates. Näiteks: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
- Uus hulk API-d on viidud stabiilsuse tasemele, sealhulgas on stabiliseeritud meetodid ja tüübispetsiifikatsioonide rakendused:
- core::error
- hint::assert_unchecked
- fs::exists
- AtomicBool::fetch_not
- Duration::abs_diff
- IoSlice::advance
- IoSlice::advance_slices
- IoSliceMut::advance
- IoSliceMut::advance_slices
- PanicHookInfo
- PanicInfo::message
- PanicMessage
Märge «const», mis määrab võimaluse kasutada igas kontekstis konstantide asemel, on rakendatud funktsioonides:
- char::from_u32_unchecked (funktsioon)
- char::from_u32_unchecked (meetod)
- CStr::count_bytes
- CStr::from_ptr
Tüüp std::panic::PanicInfo on ümber nimetatud std::panic::PanicHookInfo (vana nime kasutamine on säilinud, kuid alates järgmisest versioonist toob see kaasa hoiatuse). Samas jääb core::panic::PanicInfo selliseks nagu on, kuid areneb edasi eraldi tüübi onder. Tüüpide eraldamine võimaldab ellu viia erinevaid meetodeid, mis on spetsiifilised snd ja no_std konteksti jaoks.
- Lõpetatud üleminek ABI C-unwind ('extern "C-unwind"'), mis erineb ABI-st, millel ei ole sufiks ' -unwind' ('extern "C"'), säilitades turvalise käitumise (safe), kui 'unwinding' protsess, mida käivitab programmi ebaõnnestumine või C++-stiilis erandi genereerimine, ületab ABI piiri (näiteks kui erand, mis tekkis ühe programmeerimiskeele koodis, mõjutab teise programmeerimiskeele koodiga seotud steki lahti kerimist). Alates Rust 1.81 väljaandest on ABI 'extern "C"' aktiveeritud ebamugavuse lõpetamisel, kui lahti kerimine jäi katmata.
- Rakendatud kolmas toetaske tase platvormide jaoks i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Kolmas tase tähendab põhitoetust, kuid ilma automatiseeritud testimise, ametlike ehituste avaldamise ja koodi ehitamise kontrollimiseta.
- Rakendatud teine toetaske tase sihtplatvormide jaoks loongarch64-unknown-linux-musl ja arm64ec-pc-windows-msvc. Teine tase tähendab kokkuleppe olemasolu ehitamiseks.
- Linuxi süsteemide jaoks platvormil LoongArch on pakutud täiskomplekt ja profilatsioonitööriist.
- Ravitud haavatavus (CVE-2024-43402) std::process::Command, mis ilmnes ainult Windowsi platvormil ja kõrvaldas varem parandatud haavatavuse BatBadBut, mis oli seotud spetsiaalsete sümbolite käsitlemisega Command::arg ja Command::args kutsete puhul, mis on mõeldud argumentide vahetuks edastamiseks protsessile ilma nende käsitlemiseta käsurea tõlgendaja poolt. Tegelikult, bat- ja cmd-skriptide käivitamisel käivitati protsess cmd.exe, millel oli oma argumentide jagamise loogika. Kaitse ümberminemise mehhanism põhines sellel, et Windows eemaldab teede juures juhtivad tühikud ja punktid, st '.bat.' laiendusega fail töödeldakse kui '.bat'.
Lisaks võib mainida, et Wedson Almeida Filho lahkus Rust for Linux projekti juhendamise kohalt, mis tegeleb Rust'i arendustööriistade integreerimisega Linuxi kerneli. Wedson'i lahkumise järel jäävad projekti veel kaks juhendajat — Miguel Ojeda, Rust-for-Linux projekti looja ja peamine arendaja, ning Alex Gaynor, endine Python Software Foundation'i direktor, kes on keskendunud Rust'i edendamisele. Lahkunud juhendaja, kes liitus projektiga neli aastat tagasi, on Microsofti töötaja ja eksperimentaalse EXT2 failisüsteemi draiveri autor, mis on kirjutatud Rust'is. Viimastel aegadel oli Almeida töö keskendunud failisüsteemide arendustööriistade loomisele Rust'is. Sel aastal on Almeida teinud 17 commit'i Rust-for-Linux hoidlas (võrdluseks — Miguel Ojeda lisas 53 commit'it).
Lahkumise põhjuseks tuuakse välja jõu ja entusiasmi puudumine, mida oli kunagi piisavalt, et reageerida mõnedele mitte tehnilistele jaburustele. Almeida arvates on arendajad sunnitud kulutama palju energiat tühiste vaidluste peale, mis kõrvaldavad olulisemad globaalsete eesmärkide saavutamise võimalused. Almeida usub endiselt, et tuleviku kerneli alus on keelte kasutamine, mis tagavad mälu ohutu kasutamise, ja kui Linuxi arendajate kogukond seda ei mõista, siis tõukab Linuxi kõrvale mõni teine kernel, nagu juhtus kunagi Unix'iga.
Rust-for-Linux projekti toetajad seisavad silmitsi vajadusega ületada vastupanu vanade, kogenud kerneli arendajate poolt, kes ei näe mingit põhjust uue keele õppimiseks. Oma lahkumiskirjas toob Almeida näitena viite arutlusele, mis toimus tema ja Kent Overstreeti esinemise ajal konverentsil "Linux Storage, Filesystem, Memory-Management, and BPF Summit" ning mille fookuses oli Rust'i kasutamine failisüsteemide arendamisel. Rust'i integreerimise tegevust kritiseeris Ted Ts'o, ext2/ext3/ext4 failisüsteemide autor, kes võrdisi Rust-for-Linux algatust katsega sundida kõiki vastu võtma Rust'i religiooni.
Vastates Almeida kavatsemisele luua C-keeles faili süsteemide liideste ümberrakendus, märkis Ted Tso, et selline ümberrakendus toob paratamatult kaasa probleeme, kuna iga C-liidese muutmine ja refaktoreerimine nõuab Rusti ümberrakenduse muutmist ning ta ei soovi võtta endale liialt vastutust Rusti koodis tekkivate probleemide parandamise ja Rusti ümberrakenduse seisundi jälgimise eest. C-kood areneb pidevalt ja kui selle muutmine rikub Rusti ümberrakenduse, toob see endaga kaasa probleeme kõigile sellele liidesele toetuvatele faili süsteemidele.
Ted peab samuti seda, et lähitulevikus jääb Rusti ümberrakendus teisejärguliseks ning probleemid sidumistest saavad olema peavalu vaid Rust-for-Linux arendajatele, mitte tuumafaili süsteemide arendajate üldsusele. On märgitud, et kõik arendajad ei kavatse Rusti õppida ja seetõttu saavad nad pärast koodi muudatuste tegemist, mis mõjutavad teisi koode, värskendada ainult sõltuvat C-koodi, kuid nad ei suuda Rusti ümberrakendusi parandada, kuna ei tunne Rusti. Arutelule liitus ka James Bottomley, kes hooldab SCSI alam süsteemi, kes ütles, et mida enam semantikat kodeeritakse ümberrakendustes, seda hapramaks need muutuvad sünkroniseerimise tagamise seisukohalt.
Samal ajal on Google, kes eelmisel aastal ümber kirjutas Rusti keeles pvmfm püsivara, mida kasutatakse virtuaalmasinaid, mis käivitatakse Androidi platvormil, jagas kogemust järkjärgulise Rusti keele koodi lisamisest olemasolevatesse püsivara, mis on algselt kirjutatud C või C++ keeles. Näidatakse, kuidas püsivara turvalisust oluliselt parandada, luues identsete funktsioonidega asenduselemente, mis on kirjutatud Rusti keeles. Rusti juurutamisel on soovitatav keskenduda Rusti kasutamisele uue koodi ja turvalisuse seisukohalt kriitilise funktsionaalsuse koodi (näiteks koodi, mis töötleb usaldamatest allikatest saadud väliseid andmeid). Rusti ja C koodi integreerimiseks on soovitatav kasutada vahekihte (shim), mis tõlgivad kutsed Rusti ja C API vahel (C API eksporditakse Rusti koodi kasutamiseks ja vastupidi), mis võimaldavad järk-järgult kirjutada API elemente Rusti keeles.
Allikas: opennet.ru
