Microsoft vydal doplněk Checked C pro dynamickou kontrolu mezí v C, jak jej známe z C#. Checked C je vydáno s MIT licencí a podpora je zatím pro LLVM a clang. Bližší specifikaci Checked C lze nalézt v obsáhlém dokumentu, nebo na stránce projektu.
(zdroj: theregister)
To je uvedeno na stránce projektu.
http://research.microsoft.com/en-us/projects/checkedc/default.aspx
Nenic mu jeho pohled na svet. Doted ho mel tak jednoduchy. MS || Adobe = zlo, ostatni dobro az na pudu :D
Vždycky mě fascinuje kolik energie vydává microsoft na kvalitu kódu, ale přitom v tom dlouhodobě úplně selhává. Tenhle projekt mi připadá jako další ukázka nesmyslného přístupu k bezpečnosti. Pokud chci bezpečnost, tak v první řadě nepoužiju C. Jaký smysl má použít dialekt C, který nikdo nepodporuje a který neřeší dalších x nejběžnějších programátorských chyb?
Ze temhle to s C funguje http://man.openbsd.org/OpenBSD-current/man9/style.9 . Jestli to treba nahodou neni o tom, ze takrka vubec nesejde na jazyku, ale na tom, jestli je to fakt programator co umi a nebo hromada outsourcovaneho kanonfutru :D
Já neřikám, že C se nemá používat vůbec, ale jen tam kde je opravdu potřeba. A problém je, že naprostou většinu programů píše ten kanonfurt a stejně to nestačí a všichni si stěžují, že programátorů je málo. Takže asi těžko můžeš na všechno najmout nejlepší programátory. A ten odkaz cos poslal je popis codestylu, ale nějak tam nevidím, kde tam máš jak zabránit chybám jako třeba to zmiňované překročení mezí polí?
Kanónenfutr a ne kanonfurt. To pochází z Němečiny, kdy das Kanonenfutter značí "krmivo pro děla" nebo "krmivo děl" -- prosté pěšáky, kteří prostě nic moc neumí a jediné co je užitečné, že na ně nepřítel plýtvá municí a tedy tito vojáci ochrání ostřílené profesionály svými těly. Není to moc půvabné, nesouhlasím úplně s kvalitou toho přirovnání, protože ani špatný programátor a dokonce ani "cvičená opice" pro mně není "na odstřel". Abychom si rozuměli, každý má právo na život a já ani náznakem nechci podporovat jiný názor. To ale nebyla pointa příspěvku ctěného kolegy. Špatný programátor by neměl psát absolutně kritický kód a co nejméně kazit. Z mého pohledu je špatný programátor spíše programátor neproduktivní/ nezkušený, ne že by nutně něco kazil. Mě ale nepřísluší hodnotit schopnosti ostatních, sám nejsem žádný výkvět. Tu a tam jsem zaslechl nějaké to moudro, ale to mi ještě neuděluje žádná práva kecat ostatním do práce/ života.
Z principu musí jít v každém mírně seriózním jazyce programovat bezpečný kód, protože nakonec vše skončí v nulách a jedničkách, resp. instrukcích a změnách proudu a napětí. Nakonec si hardware řekne své a pokud se postupovalo systematicky, tedy inženýrsky, tak nakonec všechny chyby v rámci definovaného zadání musí být odstraněny. (V realitě nelze problém ohraničit, zadání se pořád mění a proto máme taky pořád chyby.) Že je používání vhodnějších nástrojů efektivní, o tom není diskuze. Haskell asi bude oproti C méně náchylný na nějaká přetečení zásobníku apod. Podobně jako se křížový šroub lépe šroubuje šroubovákem křížovým místo plochého, ale jde to obojím. (Srovnání s kladivem nebo kleštěmi by bylo nefér, protože C a Haskell vě většíně případů vedou k cíli, zatímco při šroubování kladivo k cíli často nevede.)
Přečetl jste si něco o tom projektu?
http://research.microsoft.com/en-us/projects/checkedc/default.aspx
Jedná se o dialekt C, který vám umožní vzít stávající systémový SW psaný v C/C++ (OS, DB, browser, interpreter jazyka), a doplnit do zdrojáků statickou i dynamickou typovou kontrolu. Přitom zůstane původní funkcionalita a více-méně i původní zdroják. Vyřešíte ovšem buffer overruns, out-of-bounds memory accesses a incorrect type casts, což jsou "stálice" odpovědné za většinu problémů s bezpečností a spolehlivostí SW.
Vtipné je jak Cčkoví programátoři tvrdí, že kód se dá napsat v pohodně spolehlivý, a je to jen o autorovi. Přitom třeba browsery mají každý rok stovky až tisíce bezpečnostních chyb, a to jde o parsování pár stovek html tagů. Možná společnosti jako Microsoft, Google, Mozilla a Apple nemají tak geniální Cčkové programátory :)
Další stálice je use after free (nebo obecně použití zneplatněné proměnné jako iterátory, soubory apod.) a tu tam neřeší. A problém vidím v tom, že potom co to upravíš už to není čisté C, takže to přeložíš zase jenom tím clangem. Pokud si chci dát takovou práci, abych opravil všechny zdrojáky, tak už se vyplatí použít jiný jazyk.
S posledním odstavcem naprostý souhlas. Právě použitím moderních jazyků můžeš díky lepší statické analýze a typovému systému spoustě z těch chyb předejít (viz. třeba rust od mozilly, který se právě snaží odpovědět na ty největší problémy ve firefoxu).
Nevím jestli projekt řeší use-after-free. Pokud na to koukám, tak bych nevylučoval, že to řešené je.
https://github.com/Microsoft/checkedc/releases/download/v0.5-final/checkedc-v0.5.pdf
Pokud jde o váš kód a nevadí vám že z něj pak není čisté C, tak není problém.
Ad Pokud si chci dát takovou práci, abych opravil všechny zdrojáky, tak už se vyplatí použít jiný jazyk - přepisovat kód je většinou velká chyba. Navíc mi není jasné, do čeho byste chtěl přepsat kernel OS nebo DB engine. A i kdybyste chtěl jít do vyššího jazyka (vizte Singularity OS), což je podle mě celkem dobrá myšlenka, tak to znamená velkou změnu designu, obrovskou spoustu práce, ztrátu kompatibility atd. Ve srovnání s tím může být lepší zabezpečit stávající kód, zvlášť pokud je dobře navržený.
http://research.microsoft.com/en-us/projects/singularity/#publications
Netvrdím že Checked C je nejlepší možnost nebo že bude někdy použité v praxi. Minimálně ale ukazuje jednu z cest.
Ad použitím moderních jazyků můžeš díky lepší statické analýze a typovému systému spoustě z těch chyb předejít - na tom se určitě shodneme. Ovšem zatím co na aplikační vrstvě se vyšší jazyky používají dobře, na úrovni systémového SW je to obtížnější. A kombinace problémů s výkonem a legacy code znamená že máme v C/C++ psaný nejen OS, ale i DB engine, a trestuhodně dokonce browser.
Souhlas, ta syntaxe by mohla být lepší, aby to šlo přeložit i na jiném překladači. Třeba místo ptr<T> by šlo použít ptr(T) a pak by stačilo na jiném překladači definovat makro #define ptr(T) T *, stejně tak deklarace mezí by mohla být umístěna jako funkční makro za jménem proměnná místo za dvojtečkou, pak by v jiném překladači stačilo definovat prázdné makro.
Můj tip je, že většina firem si stejně napíše tyhle obaly.
Co sa tyka takeho specifika, ako je Windowsove programovanie, tak tam je z mojho pohladu ten problem, ze:
1) najpouzivanejsi prekladac na platforme WIN64 je strasny kram. Ledabyle si to spekulativne typecastuje, nevadia mu neexistujuce tela metod, za metody analyzy sablon by sa nehnabila ani Schrodingerova macka a samotna odflaknutost prekladaca sposobuje, ze produkt uvolneny v roku 2016 moze kludne obsahovat komponenty skompilovane prekladacom (nezriedka aj vydane) v roku 2009, pretoze to mnozstvo hackov nutne k tomu, aby sebevacsi projekt slo na MSVC skompilovat to s novsim prekladacom proste nerozchodi.
2) neexistuju ziadne poriadne nastroje na staticku alebo dynamicku analyzu programov a ak ano, tak su v podstate nedostupne pre vsetkych okrem tych, ktori to s bezpecnostou kodu myslia naozaj vazne. manazeri vo velkej korporacii nezvolia k zaplateniu niekolko desiatok, stovak, alebo tisicov seatov pre drahy leak check detector alebo staticky analyzer, ak vobec nieco take trebars porovnatelne s valgrindom existuje. radsej zainvestuju do novej verzie softu na tracking projektov :) z toho, co bolo volne dostupne bol najmenej nepouzitelny visual leak detektor. s visual studiom 2015 je mozno nejaky ten detektor pouzitelny v zaklade, ale zatial som ho este pouzit nemusel. valgrind samotny na windowsoch bezi len kratku dobu aj to neviem, ci spolahlivo. staticky analyzer clang/LLVM vacsinou nejde pouzit, pretoze zdrojaky - zvlast uveci, ktore nie su cross-platformove - su obvykle napisane dialektom C++, ktory s ISO C++ nema nic spolocne.
3) akakolvek analyza cohokolvek je strasna morda. neloadla sa vam kniznica a neviete ktora alebo preco? no tak to ste v prdeli pane rediteli. zvlast ak ma aplikacia divokejsi module loader, co pre bod 4 casto aplikacie mavaju. najmenej nepouzitelny bol dependency tracker zo system internals ale vycitat z neho nieco v pripade pouzitia dynamickeho loadovania za letu, zavislosti od prostredia, working directory, pocasia alebo postavenia planet znamenalo pracu porovnatelnu so samanom na plny uvazok. alternativne sa da nejakym toolom ohackovat binarka tak, aby do debuggera grcala detailne chyby pri loadovani modulov. najlepsim priatelom kodera budiz dobre umiestnene printfy a breakpointy.
4) beznadejnost plynuca z prvych troch bodov vedie k tomu, ze programatori su strasne lajdacke prasce. microsoft raz kedysi programatorov naucil, ze klikacie IDE je dobre a od tejto generacie uplne zdegenerovala schopnost automatizovat procesy. nove generacie su starymi indoktrinovane a kultura opakovania ukonov, ktore si nezasluzia 2x po sebe pozornost od ziadneho vyssieho primata pretrvava uspesne dalej. ak uz nahodou dojde k tomu, ze nastane potencialne opakujuca sa situacia, namiesto toho, aby sa oskriptila, sa zrusi akcia, ktora riziko opakovanej operacie vyvolala. automatizuje sa nutne minimum ako generovanie instalatorov, alebo automaticke buildy a testy. kedze nikto nic neautomatizuje, nikto zaroven nic nedokumentuje, pretoze vzdy existuje niekto, kto to vie spravit rucne. ak sa uz stane taka stastna situacia, ze je nieco zautomatizovane a skript sa kvoli evolucii cohokolvek rozbije, tak programatorsky substrat sa vrati k automanualnemu vykonavaniu ukonov, pretoze je to tak jednoduchsie. ved dokumentacia nie je.
5) vsetko je nedeterministicke. jedna aplikacia bez problemov pouziva viacero verzii C-ckovych runtimeov, ktore maju rozne glitche (nas lokalny rekordman asi pouzival runtimy 4, 3 je uplne bezne cislo, 2 runtimy su uspech a 1 vlhky sen) takze ten isty kod sa moze chovat rozne podla toho s ktorou verziou runtime-u je prave zlinkovany. U vacsich projektov pisanych komponentnym sposobom sa potom moze stat ze kvoli roznym dovodom plynucim z bodov1) a 4) moze kludne jedna aplikacia vyuzivat viacero verzii nielen v pripade runtimu, ale aj v pripade vyssej kniznice. potom nastava split brain condition, binarna kompatibilita isla srat a moze dojst na hru "hadaj s cim je to tu zlinkovane". mozem potvrdit, ze je to vzdy velka sranda a dava pojmu "dependency hell" uplne nove rozmery. schvalne si skuste spravit zoznam suborov velkych komercnych balikov, kolko krat sa vam budu opakovat nazvy DLLiek, alebo aspon patterny v nazvoch suborov. Snazivi nalezcovia 4tyroch a viacerych opakovani mozu trebars nahlasit nalezy aj do fora :) debugger je nedeterministicky tiez. sem-tam sa proste rozhodne, ze nejaku premennu nedovoli prebrowsovat (tu nic nie je a to ze to v debug builde nieco robi je len vidina), nejaky vyraz neresolvne, missne breakpoint, aj ked podla vsetkych meritok je platny a trafitelny. inkrementalny prekladac je taktiez nedeterministicky, pretoze obcas missne nieco, co by sa zislo prelozit (ako by aj mohol, ked je to taky kram) a aplikacia potom vykazuje uplne nepochopitelne vady. v takom pripade je to jednoduche, staci spustit rebuild roztoku (rebuild solution) a ist sa hodinu niekde flakat. horsie je to v pripade, ked aplikacia vykazuje chovanie, ktore je uveritelne nespravne. to chce potom dobry skill v rozhodovani, ci presrat hodinu pri pozerani na prekladac, alebo vrtanim sa v kode, ktory je korektny, len to prekladac tak trocha nedal.
nie, v takychto podmienkach sa naozaj seriozna a robustna aplikacia napisat neda. nejaky memcpy s fixne danym bufrrom kopirujuci dynamicky velky payload je uz len ceresnicka na vykale. a mnoho aplikacii, ktore su X-platformove a vyskytuju sa trebars na macu, alebo nebodaj linuxe su na tieto platformy portovane prave z windowsu, pretoze bud vyvojari veria, ze tie vyvojove nastroje (zufalstvo, beznadej, neschopnost a nedeterministickost) su naozaj to najlepsie, co sa da zohnat, alebo je projekt tak sfusovany, ze by nikto jeho ocistenie nepreplatil.
to som si pri programovani presiel prakticky vsetkym od embeddov, medii, sietovych sluzieb, HA, databaz a vsetkeho na hromade, ale az na windowse som spoznal najhlbsiu uroven pekla. a to mam aspon tu vyhodu, ze pracujeme na veci, ktora je X-platformova, takze potreba skompilovat veci na inom prekladaci a systeme aspon trocha brzdi uroven pritomneho humusu.
ČLÁNKY DO MAILU