Objavljen je izid programskega jezika splošne rabe Rust 1.81, prvotno razvitega pri Mozilli, sedaj pa je v razvoju pod okriljem neodvisne nevladne organizacije Rust Foundation. Jezik je osredotočen na varno upravljanje z memory in nudi orodja za dosego visoke paralelizacije izvajanja nalog, pri čemer se izogne uporabi zbiralnika odpadkov in runtime (runtime se zmanjšuje na osnovno inicializacijo in ohranjanje standardne knjižnice).
Metode upravljanja memorijom u Rust-u oslobađaju developere od grešaka pri manipulaciji pokazivačima i štite od problema koji nastaju zbog niskonivojskog rada s memorijom, kao što su pristupanje memorijskim područjima nakon njihova oslobađanja, dereferenciranje null pokazivača, izlazak izvan granica bafera, itd. Za distribuciju biblioteka, omogućavanje gradnje i upravljanje ovisnostima razvija se paket menadžer Cargo. Za hostovanje biblioteka podržava se repozitorij crates.io.
Sigurno upravljanje memorijom u Rust-u osigurano je tokom kompajliranja pomoću provjere referenci, praćenja vlasništva nad objektima, uzimanja u obzir vremena života objekata (vidljivost) i procjene ispravnosti pristupa memoriji tokom izvršavanja koda. Rust takođe pruža sredstva za zaštitu od prelivanja cijelih brojeva, zahtijeva obaveznu inicijalizaciju vrijednosti varijabli prije korišćenja, bolje obrađuje greške u standardnoj biblioteci, primjenjuje koncept nepromjenjivosti (immutable) referenci i varijabli kao podrazumijevano, te nudi jaku statičku tipizaciju za minimiziranje logičkih grešaka.
Glavne novosti:
- Stabilizirana je bila vrsta core::error::Error, ki opredeljuje opisne napake. Ta sprememba omogoča uporabo enotne vrste Error v različnih knjižnicah, neodvisno od okolja, vključno s knjižnicami, ki niso povezane s standardno knjižnico, in uporabljajo atribut «#![no_std]».
- Stabilne in nestabilne funkcije za razvrščanje v standardni knjižnici so bile preusmerjene na uporabo novih algoritmov, ki pokažejo višjo hitrost delovanja in krajši čas prevajanja. V implementaciji novih algoritmov za razvrščanje je bilo zagotovljeno prepoznavanje nepravilno definiranih vrst Ord in v takih primerih je bila preusmerjena napaka (panic) namesto naključno združenih podatkov.
- V linterju je bil uveden nova raven preverjanja «expect» («#[expect(lint)]»), ki omogoča potrjevanje izvajanja preverjanja in izpis opozorila, če preverjanje ni opravljeno (zaradi napake v implementaciji ali izklopa preverjanja). Na primer, pri prenosi kode na uporabo preverjanja undocumented_unsafe_blocks preko Clippy lahko navedete «#[expect(clippy::undocumented_unsafe_blocks)]», da se prepričate, da bodo vse unsafe-bloke med prehodom dokumentirane. V Clippy so bili prav tako uvedeni pregledi clippy::allow_attributes in clippy::allow_attributes_without_reason, ki poenostavijo zamenjavo atributov «#[allow]» z «#[expect(lint)]».
- Omogočeno je dokumentiranje razlogov za zamenjavo ravni preverjanja (lint), kar novim razvijalcem nudi informacije o razlogih za dodajanje določene preverjanja, kar se izpisuje kot sporočilo prevajalnika. Na primer: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
- У розряд стабільних переведено нову порцію API, зокрема стабілізовані методи та реалізації типажів:
- 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
Признак «const», що визначає можливість використання в будь-якому контексті замість констант, застосовано у функціях:
- char::from_u32_unchecked (funkcija)
- char::from_u32_unchecked (metoda)
- CStr::count_bytes
- CStr::from_ptr
Тип std::panic::PanicInfo был переименован в std::panic::PanicHookInfo (предыдущее имя останется доступным, но начиная с следующей версии его использование приведёт к выводу предупреждения). В то же время core::panic::PanicInfo останется без изменений и будет развиваться как отдельный тип. Разделение типов позволит реализовать в них различные методы, специфичные для выполнения в контексте snd и no_std.
- Завершён переход на ABI C-unwind (‘extern «C-unwind»‘), который отличается от ABI без суффикса «-unwind» (‘extern «C»‘) сохранением безопасного поведения (safe), если процесс «размотки» (unwinding), инициируемый во время аварийного завершения программы или генерации исключения в стиле C++, пересекает границу ABI (например, когда исключение, возникшее в коде на одном языке программирования, при размотке затрагивает стек, связанный с кодом на другом языке программирования). Начиная с выпуска Rust 1.81 в ABI ‘extern «C»‘ задействовано аварийное завершение при неперехваченной размотке.
- Реализован третий уровень поддержки для платформ i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Третий уровень подразумевает базовую поддержку, но без автоматизированного тестирования, публикации официальных сборок и проверки возможности сборки кода.
- Реализован второй уровень поддержки целевых платформ loongarch64-unknown-linux-musl и arm64ec-pc-windows-msvc. Второй уровень поддержки подразумевает гарантии сборки.
- Для Linux-систем на платформе LoongArch предоставлен полный инструментарий и профилировщик.
- Устранена уязвимость (CVE-2024-43402) в std::process::Command, проявляющаяся только на платформе Windows и устраняющая обходной путь эксплуатации ранее исправленной уязвимости BatBadBut, связанной с обработкой спецсимволов при использовании вызовов Command::arg и Command::args, которые предназначены для прямой передачи аргументов процессу, без обработки командным интерпретатором. На деле при запуске bat- и cmd-сценариев запускался процесс cmd.exe с собственной логикой разделения аргументов. Обход защиты основан на том, что Windows удаляет лидирующие пробелы и точки в путях, т.е. файл с расширением «.bat. .» обрабатывается как «.bat».
Poleg tega je mogoče omeniti odhod Wedsona Almeide Filha s položaja vzdrževalca projekta Rust for Linux, ki se ukvarja z uvedbo orodij za razvoj v jeziku Rust v jedro Linuxa. Po odhodu Wedsona sta pri projektu ostala še dva vzdrževalca — Miguel Ojeda, avtor in glavni razvijalec projekta Rust-for-Linux, ter Alex Gaynor, nekdanji direktor organizacije Python Software Foundation, ki se je preusmeril v promocijo Rust. Odhajajoči vzdrževalec, ki se je projektu pridružil pred 4 leti, je zaposlen pri podjetju Microsoft in je avtor eksperimentalnega gonilnika s implementacijo sistema datotek EXT2, napisanega v jeziku Rust. V zadnjem času je bilo delo Almeide osredotočeno na razvoj orodij za razvoj sistemov datotek v jeziku Rust. Ta leto je Almeida prispeval 17 prenov v repozitorij Rust-for-Linux (za primerjavo, Miguel Ojeda je dodal 53 prenov).
Kot razlog za odhod se omenjata pomanjkanje moči in entuziazma, ki sta nekoč obstajala za obvladovanje nekaterih nepomembnih zadev. Po Almeidaovem mnenju so razvijalci primorani porabiti veliko energije za razprave o nesmrtnosti, kar spodkopava bolj pomemben globalni cilj. Almeida še vedno verjame, da je prihodnost jedra v uporabi jezikov, ki zagotavljajo varno delo z jepom, in če skupnost razvijalcev Linuxa tega ne razume, bo Linux nadomestil kakšno drugo jedro, kot se je nekoč zgodilo z Unixom.
Podporniki projekta Rust-for-Linux se soočajo z nujnostjo premagovanja odporov veteranov starih razvijalcev jedra, ki ne vidijo potrebe po učenju novega jezika. V svojem odstopnem pismu Almeida kot primer navaja povezavo na razpravo, ki je potekala med nastopom Almeide in Kenta Overstreeta na konferenci „Linux Storage, Filesystem, Memory-Management, and BPF Summit“, in je bila posvečena uporabi Rust pri razvoju sistemov datotek. Ted Ts'o, avtor sistemov datotek ext2/ext3/ext4, je kritiziral prizadevanja za uvedbo Rust in jih primerjal s poskusom, da bi vse prisilili v sprejetje religije Rust.
V odgovoru na namero Almejda, da ustvari obvezo nad vmesniki datotečnih sistemov, napisanimi v jeziku C, za njihovo uporabo v kodi v jeziku Rust, je Ted Zo opozoril, da bo taka obveza nujno privedla do težav, saj bo vsaka sprememba C-vmesnikov in izvedba refaktoringa zahtevala spremembo obveze za Rust. Ne želi prevzeti dodatne odgovornosti za reševanje težav v kodi Rust in spremljanje stanja Rust-obveze. Koda v jeziku C se nenehno razvija in če sprememba moti delovanje obveze za Rust, bo to povzročilo motnje v delovanju vseh povezanih datotečnih sistemov.
Ted prav tako meni, da bo obveza za Rust v bližnji prihodnosti ostala sekundarna in da bodo težave v bindih bolečina samo za razvijalce Rust-for-Linux, ne pa za skupnost razvijalcev datotečnih sistemov v jedru. Opozarjeno je, da se ne vsi razvijalci nameravajo učiti jezika Rust, zato bodo po spremembah, ki vplivajo na drugo kodo, lahko posodobili le odvisne kode v jeziku C, ne bodo pa mogli popraviti Rust-obvez, saj ne obvladajo Rusta. Razpravi se je pridružil tudi James Bottomley, ki skrbi za podsistem SCSI, ki je dejal, da čim večja semantika, ki je kodirana v obvezah, tem bolj krhke postanejo z vidika zagotavljanja usklajenosti.
Medtem pa je podjetje Google, ki je lani prepisalo programsko opremo pvmfm v jezik Rust, uporabljeno v virtualnim mašinama, ki se izvajajo na platformi Android, je delila izkušnje postopnega vključevanja kode v jeziku Rust v obstoječe vdelane programske opreme, prvotno napisane v C ali C++. Prikazano je, kako lahko znatno povečate varnost vdelane programske opreme z ustvarjanjem identičnih funkcionalnih komponent zamenjav, napisanih v jeziku Rust. Glavno pozornost pri uvajanju Rust je priporočljivo posvetiti uporabi Rust za novo kodo in kodam, ki opravljajo naloge, kritične z vidika varnosti (na primer koda za obdelavo zunanjih podatkov iz nezanesljivih virov). Za integracijo kode v Rust in C se priporoča uporaba plastenic (shim), ki prevajajo klice med API-ji v Rust in C (C API je izvozno za uporabo v kodi v Rust in obratno), kar omogoča postopno prepisovanje elementov API v Rust.
Izvor: opennet.ru
