Bezpecnost nemuzete definovat stylem: kdyz to pouzijete takhle tak je to bezpecne.
Jistěže můžete. Jiný přístup by často vedl k nepřiměřené složitosti. Doprostřed silnice buď můžeme postavit betonovou zeď, nebo tam namalujeme čáru a vedle postavíme značku "zákaz předjíždění". Podobným mechanismem je řešena bezpečnost i v jaderných elektrárnách (barevně odlišené oblasti na podlaze, znamenající prostor pro kontaminované předměty, zákaz přetěžovat operátory v řídícím softwaru apod.), v leteckém provozu, pomocí MISRA pravidel atp.
IEC61508 to vidí trochu jinak
Vidí to přesně jak jsem napsal. Je třeba posuzovat dopady selhání a jejich pravděpodobnost a podle toho volit vhodné nástroje.
třeba jazyk podle žádané SIL, to co tu píšete vyznívá jako, že na jazyku nezáleží, stačí coding guidelines
Na jazyku ale opravdu z hlediska těchto standardů a doporučení záleží pramálo. Těžko by taky prošel nějaký konkrétní jazyk. Klidně vám to řeknu, jak to funguje, protože už jsme dodávali více safety-critical software.
Zákazník si stanoví podmínky, obvykle "dle ISO...", "dle DO-178" apod. Tyhle standardy ale nespecifikují žádný konkrétní jazyk. My jen v protokolech pro audit musíme vypsat, jak jsme se vypořádali se všemi požadavky, jež jsou těmito standardy na nás kladeny, pokud jde o vývojový cyklus, o testování, o coding guidelines/policies. Ovšem ani tady to není úplně striktní, požaduje-li něco např. MISRA, stále můžeme zadavateli navrhnout odchýlení se, protože v daném případě nám daný požadavek připadá jako kontraproduktivní, nebo specifikovat jiné požadavky (zákaz podmíněného operátoru, povinnost inicializovat alespoň na neplatnou hodnotu hned při deklaraci, maximální/průměrná cyklomatická složitost...)
Obecně platí, že nejzásadnější je mít k dispozici certifikované produkty třetích stran, tj. překladač a knihovny. Takové najdete pro C, pro C++, Adu, Pascal, Fortran, COBOL, Javu, ale bude mít i Rust a s ním používané knihovny potřebný certifikát dle zadavatelova standardu? Protože pokud ne, tak i kdyby v daném jazyku nebylo možné se ani křivě podívat na zdroják, stejně bude z tohoto hlediska nepoužitelný. Překladač s knihovnami certifikovaný na všechny ty možné standardy najdete snad jen u Ady a - kdo by to řekl - u C/C++.
Jinými slovy - ano, i ten nejkritičtější software je možné psát - a taky se píše - v C, potažmo v C++, a to i přesto, že tu s námi už dávno jsou jazyky, které jsou považovány za blbuvzdornější než tyto dva výše jmenované.
Mimochodem - víte o nějaké statistice, která by dokládala, že software napsaný v nějakém tom "bezpečnějším" jazyce je opravdu spolehlivější a jeho vývoj a údržba stály méně peněz v porovnání s "nebezpečným" jazykem? Mám obavy, že americké ministerstvo obrany postupně ustupuje od Ady právě kvůli tomu, že žádný takový závěr se jim nepodařilo prokázat. Ostatně ani Erlang se v Ericssonu ani zdaleka nestal hlavním vývojovým nástrojem, jak se původně plánovalo - hardware tam dnes programují v C/C++ (snad jsem teď nevyzradil nějaké jejich korporátní tajemství) a Erlang tam spíše jen dožívá na starších projektech.
Praxe zkrátka ukazuje, že ty inherentní bezpečnostní prvky některých jazyků nejsou zas takovou evoluční výhodou, jak by se na první pohled mohlo zdát.
101 Odpovědí
14890 Zhlédnutí