Rust sem hibátlan

Volt valamikor egy szál itt a fórumon, ahol az felmerült, hogy mi van, ha egy biztonságos programozási nyelv fordítója környékén van valami hiba.
Sikerült találni egyet:
    https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html

Vajon maradt-e még benne súlyosabb, fel nem fedezett hiba?

( volo v | 2022. 01. 21., p – 08:06 )

Biztos, hogy maradt, csak idő kérdése, hogy mikor bukkan elő.

( XMI | 2022. 01. 21., p – 10:36 )

Mondjuk egy TOCTOU versenyhelyzet eleve magasabb szintu hiba, mint amit egy biztonsagos programozasi nyelv elvileg ki tudna vedeni.

Ez sem a forditoban van, hanem a standard library-ben.

Régóta vágyok én, az androidok mezonkincsére már!

( joco01 v | 2022. 01. 21., p – 11:03 )

Szerintem túlzás és kontraproduktív a Rustot biztonságosnak nevezni. Esetleg a memóriakezelése biztonságos, mint pl. Java vagy C# vagy szkriptnyelvek esetén. De millió másféle sechole-t egy nyelv nem tud megakadályozni.

( hg2ecz v | 2022. 01. 21., p – 11:07 )

Szerkesztve: 2022. 01. 21., p – 11:08

Egyébként a nagyobb kockázat itt is a közösség által összedobott modulok (https://crates.io/) körül van.
Nem véletlen, hogy a cargo check ellenőrzi, van-e valami CVE az adott modul általad hozzáfordítani kívánt verziójában.

( Elbandi v | 2022. 01. 21., p – 13:40 )

a kerdes hogy noveli-e a biztonsagot a rustban valo programiras egy C/java/akarmi-hez kepest.

biztonsagi ov hasznalata mellett is halnak meg emberek balesetkor. akkor most dobjuk ki a bizonsagiovet?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hát egy picit többről szól. Például az időközben alappá változott konkurens programozásra is ad biztonságos megoldásokat.

Csak egy példaként gondolj arra, hogy hogyan adtuk át a szálak között C-ben adatokat. Globális struktúrában?
Globális írható változó a Rust safe módjában nem lehetséges, ha megfeszülsz akkor sem. Ezzel egy csomó programozástechnikai hiba lehetősége el is van kerülve.
Helyette marad a Rust-féle mpsc::channel és az sync::arc szemaforozott átadás, azaz a biztonságos irány. És még sok apróságot megoldottak a programozás merev szabályok közé terelésével.

Apropó sok szál: a rayon csomag szintén telitalálat. A legegyszerűbb módon iterátorral robbantod sok magon párhuzamosan futó szálakra a feladatot.
És itt is a kulcsmondat: "No data races".

Inkább leírom, mert egyszerű. A threadekhez tartozó struktúrákat, amiket a pthread_create()-nek átadsz az arg paraméterben, azokat bárhol allokálhatod, nem kell, hogy globálisak legyenek és ezekbe nyugodtan belepakolhatod más threadek hasonlóan allokált struktúrájának a pointereit is, amikhez azt akarod, hogy hozzáférjenek. Ezeket aztán átadod azoknak a függvényeknek, amik a threadek struktúrájának írogatását/olvasgatását végzik. Persze nyilván lehet a pointeren keresztül közvetlenül is írni/olvasni a másik thread cuccait, de akkor minden egyes thread start_routine-jában le kell implementálni ugyanazokat a mechanizmusokat a szemaforozáson át a validálásig, szóval jobb, ha az ember egyszer megírja ezeket egy-egy függvényben és utána az adott elemet azzal tudja piszkálni minden egyes elérhető thread struktúrájában.
Ily módon egy thread csak azon a threadek adatait tudja írni/olvasni, amikhez hozzáférést akarsz nekik adni és akkor egyáltalán nincs és nem is kell semmilyen globális változó vagy struktúra amit a threadek piszkálnak, mert a threadek egyszerűen egymással kommunikálnak a hívásokon keresztül.

Az, hogy esetleg ez C-ben nem szokás, az lehet, de megoldható.

Oldschool Computer - http://oscomp.hu

( thuglife | 2022. 01. 21., p – 18:38 )

Szerkesztve: 2022. 01. 21., p – 18:40

En nem ertem mire varnak... ujra kellene irni Rust-ban. Oh wait.

Ez a bajom a fashion computing-al, olyan hibakat javitanak vagy kell javitani amit 30-40 eve mar megoldottak.

Ahogy olvastam, a Rustnak van egy butított részhalmaza, pl mikrokontrollerhez, úgyhogy miért is ne. Másrészt olyan nyelv, ami GC nélkül oldja meg, amihez a Java-nak pl komplett VM kell, azért értékes tud lenni és nem is olyan újkeletű, más kérdés, hogy egyesek szerint minimális odafigyeléssel, már C-ben vagy C++-ban se kéne, hogy gondot okozzon a memóriakezelés, bár én a kék C könyvön túl nem nagyon jutottam, max egy kis mikrokontrollerezés volt még rég. Inkább belepunnyadtam a Java fotelbe...

ARM Cortex M3-ra volt tavaly egy céges projektem Rustban. Azon kívül, hogy az std lib-et, aminek sérülékenysége kapcsán ezt a témát indítottam, nem fordítottam hozzá ( #![no_std] ), cserébe a cortex-m crate-et használtam. Maga a fordító teljes értékű, az std-ben levő dolgok viszont ekkor hiányoznak. Ellenben a cortex* csomagokból a mikrovezérlős feladathoz sok aranyos dolog jön.

( uid_21476 | 2022. 01. 22., szo – 23:42 )

mi van, ha egy biztonságos programozási nyelv fordítója környékén van valami hiba.

Adát kell használni.
Nem biztos, hogy jobb, de valószinűleg kellemesebb. Gumival még biztonságosabb is.