Kolem 70 % vážných bezpečnostních chyb v Chromiu jsou chyby používání paměti

je smutný, že jazyk (c/c++), na kterém jsem vyrostl nezadržitelně umírá, sestupnou tendenci lze pozorovat dlouho. V součastnosti je jen pár zkušených týmů, kteří jsou schopni psát kód bezpečně a je to příliš drahé, učící křivka příliš dlouhá.

[Tomas2]
Podle me jej zabiji zmlsanost a urcita ... hmmm zlenivelost pochazejici z vyssich jazyku - vyhoda pro me, nevyhoda pro C++. Ale myslim, ze jeste dlouho (mozna vzdycky) budou existovat obory, kde bude vyhodnejsi sahnout po C/C++. Ale tak jako tak je to velka skoda.

V čem je to škoda? Očividně je to fabrika na chyby a desítky let snah s tím nic neudělaly. Čas jít jinam... Byl už dávno.

[Ondra Satai nekola]
Ty si bez kam chces, ja u C++ zustavam, lepsi jazyk podle/pro me zatim vymyslen nebyl.

Jak na co...

Každopádně by mne fakt zajímalo, kolik jazyků jsi potkal.

No neviem, ale ja osobne radšej používam C/C++ než Javu, C#, a iné podobné jazyky... môj list jazykov je:

1. JavaScript
2/3. C/C++
2/3. Golang
(stále sa neviem rozhodnúť medzi nimi v poradí v rebríčku)
4. Python
5. Raku
6. ERLang
.
.
.
X. ostatné jazyky

a tiež sa mi nepáči jak to C/C++ začína ísť do kytek.

25. 5. 2020, 19:10 editováno autorem komentáře

[Mlocik97]
Naopak, me velmi tesi, ze porad existuji lide, kteri jeste na C/C++ nezanevreli.

#include<iostream>

int main( int argc, char **argv )
{
  std::cout << "C++ is really best" << std::endl;
  return 0;
}

Ten nešťastný příklad s přetíženým << tomu nasadil korunu!

Roste tlak na cenu, to je celé. Dnes existují dobré jazyky s vyšším množstvím dokončené práce za jednotku času, tak se přirozeně dostávají do popředí tam, kde to je možné. GUI aplikace, kde se iteruje velkou rychlostí, kde se požadavky mění několikrát do roka, kde chyba nemá závažné důsledky (prostě se to v příští verzi opraví)... tam je na dnešní dobu jazyk jako C moc drahý.

V mém oboru (embedded)... je C pořád #1, a ještě velmi dlouho bude. Je to lehká abstrakce nad dnešními procesory, proto je to ideální jazyk k vývoji kernelů operačních systémů, firmwaru a dalších programů, které mají blízko k železu.

bezpečnost a cena spolu souvisí, chyby stojí peníze.

tlak na cenu byl vždy, ale neexistovaly bezpečné a současně rychlé jazyky jako Rust

26. 5. 2020, 08:42 editováno autorem komentáře

Chyby stojí peníze (reputaci) jen když koncový uživatel není pasivní a tolerantní ovce. A to my jsme. Stačí se podívat třeba na současnou Android scénu. Ani nejvyšší cenová není bez ochromujících chyb, a to i hardwarových... ale my si stejně koupíme za rok další. Překvapivě rychle se smíříme s různými obezličkami (třeba že foťák se spouští až napodruhé, že po posledním updatu vydrží baterie jen jeden den, ...) i u zařízení za skoro 30 tisíc, a tak má výrobce zpětnou vazbu maximálně v podobě nějakého rantu někde v diskuzi.

Aplikace pro nekonečně tolerantní ovce se dneska nedělají v C++. Výjimkou jsou hry, kde se C++ používá především proto, že enginy, frameworky a další nástroje už jsou pro C++, a také proto, že začít používat úplně nový jazyk by představovalo riziko, které žádný projektový manažer logicky (a správně) nechce podstoupit v kontextu, kde vývoj produktu stojí obrovské peníze a jeho komerční životnost, během které se musí investice vyplatit, je potenciálně v řádu několika měsíců.

Klientské aplikace jsou jen malá část SW a i tam mohou chyby způsobit velké škody. Ne všechny chyby způsobí jen pád aplikace, mohou způsobit únik dat, vyřazení služby, poškození dat, zápis škodlivých dat.

Je to smutné z nostalgických důvodů, nebo proto, že se software zhoršuje? Řekl bych, že je to spíš to první. Jako parní lokomotivy – mají své nezastupitelné místo v historii, je krásné se s ní jednou za rok projet na výletě z dětmi, ale dojíždět tím každý den do práce bych nechtěl.

Jo, to je fakt super, ze server bez ochrany pameti zbuchne cely kvuli chybe nejake prilinkovane knihovny.

Zrovna na tom novellu to byla prevelika krasa, kdyz se na tom pokouselo prozozovat Apache.

Este lepsi ovsem bylo, kdyz si clovek vyrazil pakl dernych stitku, s tim zasel do datacentra, sjel derne stitky, precetl si chybu a druhy den sel iterovat znova.

[Filip Jirsak]

Reknete mi Filipe, kdo bude tu Lokomotivu povazovat za zastaralou a nepouzitelnou? Vy ktery milujete svistot svho Pendolina, nebo ja, ktery tou lokomotivou stahuji z celeho okresu vsechny nakladky dreva?

Parni lokomotivu bude povazovat za zastaralou clovek, ktery by rad vyssi ucinnost nez 10%.

A C++ povazuje za zastaraly clovek, ktery ma rad ochranu pameti ve stylu Rustu.

[Youda]
Takze to mam chapat, tak ze jedna jedina vlastnost - zde dejme tomu automatizace zpravy pameti - je ten hlavni faktor pro urceni zda je jazyk moderni a pouzitelny? A vsechny ostatni vlastnosti jazyka(/u) jsou naprosto nepodstatne? A napadlo vas, ze to co konkretne Vy povazujete za zastarale, neuzitecne, potencionalne nebezpecne, popripade nehodne tohop aby jste s tim stracel Vas drahoceny cas, nekdo jiny muze povazovat prave za velmi uzitecnou vlastnost, ba mozna je velmi rad, ze spravu pameti ma ve svych rukou?

Kdo v C/C++ umí psát opravdu bezpečně? A tím nemyslím jednoduchou aplikaci o 10K řádků, ale něco rozsahu srovnatelného s Chromiem, které má v C+C++ přes 14M řádků, když nepočítám komentáře a prázdné řádky: https://www.openhub.net/p/chrome/analyses/latest/languages_summary

25. 5. 2020, 22:57 editováno autorem komentáře

Zajimava otazka a jestli mohu, zeptam se z jineho uhlu: Existuje vubec jazyk, v nemz lze psat naprosto bezpecne a neprustrelne JAKYKOLIV rozsahly projekt?

Kdyz nad tim uvazuji, asi bych - za sebe - odpovedel, ze to neni vubec otazka jazyka jako takoveho. Podle me jsou tri hlavni faktory ktere to ovlivnuji:
1) Ucel vysledneho produktu
2) Rozsah a komplexnost
3) Navrh
Hodne to zjednodusuji a uvedomuji si, ze o tom se napsalo tuny obsahlych odbornych pojednani, ale myslim, ze pro ilustraci to staci. Napr o mame tu chrome a naproti tomu dejme tomu Kate (vubec netusim jak moc je rozsahly, ale dovolim si do toho zapocitat KDE Libs a Qt a je z toho moloch ja krava). Slysel nekdy nekdo, ze by byla zneuzita nejaka dira v Kate?

Takže jste asi viděl nějaké zranitelnosti v PHP skriptech, a přišlo Vám jich hodně. Může být. Ale víte, jak by to dopadlo, kdyby PHP byl memory-unsafe?

[J ouda]
Ano, ja to vidim podobne.

Jistě hraje roli spousta věcí a technicky vzato zranitelnost může obsahovat i celkem jednoduchý vzoreček v Excelu.

Nicméně C/C++ má ve srovnání s mnohými jazyky o celou třídu potenciálních zranitelností víc, a podle této zprávičky to není jen teoretický problém.

Ano, MLoC je jen orientační metrika, záleží na spoustě dalších věcí. Budu jako příklad brát i jiné kusy softwaru, které jsou dostatečně rozsáhlé (možná ne nutně jako Chromuim, ale neměl by to být softwarevyvinutelný jako one-man-show) a dostatečně interagují s rizikovým okolím. Myslím, že Kate až tolik neinteraguje s nebezpečným okolím. Analogicky by šlo udělat rozsáhnou aplikaci, která se ale nějak obejde bez dynamické alokace paměti. Tam taky neuděláte use-after-free.

A pokud se bavíme o reálném zneužití zranitelnosti a nejen o její přítomnosti, vstupuje tu do hry i další faktor. Jak moc se aplikace reálně používá s potenciálně nebezpečným vstupem. Prohlížeč běžně. Textový editor teoreticky můžete, ale na vývoj tím můžete otevírat třeba i jen svoje důvěryhodné soubory. Takže třeba https://github.com/vim/vim/commit/d0b5138ba4bccff8a744c99836041ef6322ed39a#commitcomment-19938002 dost možná prošla bez zneužití, ve webovém prohlížeči nebo v serverovém softwaru by podobná chyba mohla vyústit v hromadné útoky. A běžný franta uživatel si pokročilejší editor plaintextu ani nebude instalovat. Software pak může být napsán řádově hůře, a přitom se případné zranitelnosti nebudou až tolik zneužívat. A nejspíš se nebudou ani tolik hledat, takže statistiky objevených zranitelností mohou u podstatně hůře napsaného softwaru vypadat lépe.

Prakticky vzato: Pokud se takovéto programátory nepodařilo sehnat Googlu v dostatečném množství a přes všechna ta opatření završená jejich štědrým Vulnerability Reward Programem*, nedá se moc čekat, že se těmto problémům vyhnu výběrem dobrých programátorů.

*) VRP typicky nebývá to úplně první opatření. Jinak by to byl celkem drahý pronájem různých (i volně dostupných) automatizovaných nástrojů, zvlášť u open-source. Ostatně Google z VRP paušálně vylučuje (nebo aspoň vylučoval) nedávné akvizice.

[Vit Sestak]

Dekuji za reakci, Ja si myslim, ze to vidime oba velice podobne. Az na to, cemu dame ten finalni vyznam, dokonce souhlasim i s Vasim zaverem. Rozdil je jen v tom, ze osobne bych necekal ze pri slozitosti a ucelu Chrome dosahnou o moc lepsich vysledku pouhym pouzitim jineho jazyka v projektu.

Myslenka s Kate je v tom, ze si myslim, ze ona neduvera v C++ je dana hlavne tim, co se v psychologii naziva survivorship Bias (zkresleni prazivsich) V nasem pripade jde o to, ze budeme prirazovat vetsi vyznam projektum, u kterych se chyby nasli a projekty ktere bezi bezproblemove (a ja ale netvrdim, ze tam chyby byt nemohou) vicemene nikoho v tomto hledisku nezajimaji a tak se jevi, ze psani rozsahlych projektu v C++ zakonite vede k chybovosti, nebo rovnou k realne zneuzitelnym zranitelnostem. Protoze ty ostatni jsou ignorovany.

A obavam se ze to neni otazka jen C++, ale v podstate jakehokoliv Jazyka. A taky toho, ktery jazyk mi je sympatictejsi.

Zajimava otazka a jestli mohu, zeptam se z jineho uhlu: Existuje vubec jazyk, v nemz lze psat naprosto bezpecne a neprustrelne JAKYKOLIV rozsahly projekt?
Původní důležitou otázku jste posunul do nesmyslu. Samozřejmě dává smysl používat jazyky, ve kterých lze psát bezpečněji. To, že to stále není naprosto bezpečné a neprůstřelné je sice škoda, ale je to pořád lepší, než psát v jazycích, které jsou k těm chybám náchylnější.

Podle me jsou tri hlavni faktory ktere to ovlivnuji
Můžete mít pět aplikací, které budou mít tyhle tři faktory stejné, ale každá aplikace bude napsaná v jiném jazyce. Dává smysl jazyky porovnávat podle toho, která aplikace bude nejbezpečnější. Stejně jako dává smysl je porovnávat podle toho, která bude nejrychleji napsaná, která nejsnáze udržovatelná, která bude mít nejmenší nároky na hardware tak, aby měla použitelnou odezvu.

Slysel nekdy nekdo, ze by byla zneuzita nejaka dira v Kate?
To ovšem vůbec nevypovídá o tom, zda tam bezpečnostní chyby jsou nebo nejsou. Může to vypovídat jenom o tom, jaká je příležitost je zneužít. Také jsem nikdy neslyšel o tom, že by někdo vyloupil vlakové nádraží, zatímco vyloupení banky je oproti tomu častý jev. Ale vůbec to neznamená, že jsou nádraží lépe zabezpečená, než banky.

[Filip Jirsak]
"Původní důležitou otázku jste posunul do nesmyslu. Samozřejmě dává smysl používat jazyky, ve kterých lze psát bezpečněji. To, že to stále není naprosto bezpečné a neprůstřelné je sice škoda, ale je to pořád lepší, než psát v jazycích, které jsou k těm chybám náchylnější."

Obavam se, ze ja jsem v teto chvili vubec predrecnika neptal na to co dava smysl ci ne. Ja jsem se ptal, zda existuje realne jazyk, v nemz se daji bezpecne a bezchybne psat velke komplexni projekty. O smyslu tam v tuto chvili nebylo ani slovo.

Hlavně existují jazyky, kde se spousta věcí řeší daleko méně ceremoniálně. Nejsem žádný velký programátor, ale něco málo C, Javy, Pythonu apod. jsem viděl v různých kontextech.
Od nějaké velikosti projektu stejně už nikdo neví, co se skutečně děje a jaké instrukce se procesoru pošlou (natož v jakém pořadí se potom skutečně vykonají, a po zkušenosti Meltdown apod. se zdá, že to relevantní je). Je tedy příležitost zvolit vyšší, robustní a hlavně konzistentní abstrakce a nechat vnitřnosti nějakému chytrému AOT/ JIT kompileru. V poslední době se zabývám ve volných chvílích Clojure a Clojurescriptem, protože mám možnost nahlédnout do projektu (https://orgpad.com/about), který je napsaný výhradně v této kombinaci. Kdybych viděl Clojure před Javou, tak se Javou nebudu zabývat, protože prakticky všechno, co umí Java umí Clojure taky a velmi často stručněji, konzistentněji a s poměrně malou námahou se dá leccos sdílet mezi Clojure a Clojurescriptem - takže Client a Server můžou sdílet dost kódu. Ano, na pár věcí se hodí vědět, jak to JVM a jiné VM nad kterými nějaký dialekt Clojure beží implementují, třeba když chcete mluvit s nějakou C knihovnou z Clojure. Tam potom koukáte na věci typu JNI, JNR apod. Na většinu běžných úkolů, kdy taháte nějaká data z databáze, máte nějakou logiku a komunikaci Client-Server, tam se s přednostmi Clojure/ Clojurescript kombinace dost špatně drží krok.

V moderním C++ se dá psát na velice vysoké úrovni abstrakce, řekl bych i v porovnání s Rustem, můžete skrýt některé detaily.

JIT kompilery se ukázaly jako slepá cesta. Podle mě se od nich ustupuje.

26. 5. 2020, 12:09 editováno autorem komentáře

"Slysel nekdy nekdo, ze by byla zneuzita nejaka dira v Kate?"

Nevím, já jsem ještě neslyšel, že by byla použita Kate. Zneužití díry je až o level výš.

Tohle je lichý argument. Možná někomu dělá dobře, že sám sebe ujišťuje, jaký je l33t R3aL Pr0gr4mm3rZ, ale uživateli i zadavateli je to srdečně jedno - a pokud není, měl by se snažit dospět nebo případně se obrátit na psychiatra. V praxi je u softwaru důležitých pět věcí (v náhodném pořadí): výkon, cena, bezpečnost, featury, uživatelská přívětivost. Dejme tomu, že přívětivost nezáleží na použitém jazyku (o tom se dá diskutovat, ale budiž). Z hlediska vyvinutých featur za nejnižší cenu nemá C++ šanci proti Pythonu, Go a podobně. Z hlediska výkonu zaostává za C, Fortranem a Rustem. Z hlediska bezpečnosti je důležitá prokazatelnost, ne jenom ujišťování a ego, a v tom je C++ absolutní katastrofa, tady vede Rust, Ada a Haskell. C++ má dosud své nezastupitelné místo díky tomu, že pro něj existuje mnohem víc nástrojů, než pro objektivně lepší jazyky, podporuje víc cílových platforem a mnohem víc lidí s ním umí. To ale neznamená, že by neměl být tlak na jeho postupné opouštění. Tvrzení že "dobrý programátor" dokáže napsat dobrý kód i v C++ je na stejné úrovní, jako že "dobrý řidič" dokáže jet i s autem s prasklými pneumatikami a které nemá brzdy. U mě to spíš vyvolává pocit, že takový "programátor" až tak dobrý není, když ani nedokáže pochopit, jak velká výhoda je, když někdo vyrobí auto, které stojí polovinu a jezdí zadarmo nebo vymyslí nezničitelné pneumatiky.

Neříkám, že můj styl je geniální, ale problémy v C++ fakt nemám a píšu podle mne bezpečně

Například burzovní robot

https://github.com/ondra-novak/mmbot

Což je prakticky one-man show. Na tak malém projektu může být celkem jednoduchá a predikovatelná alokace/dealokace paměti. Oproti prohlížeči, kde máte celkem komplexní webovou stránku ovládanou javascriptem, je to neporovnatelný rozsah. Ostatně si můžete všimnout, že polovina těch chyb s pamětí tvoří use-after-free. To není primitivní implementační chyba jako buffer overflow, to prostě znamená, že někdo někde zapomněl pointer po dealokaci a dál ho používal. Což se v tak rozsáhlé aplikaci (řádově rozsáhlejší než váš bot) hlídá poměrně těžko.

Škoda, že Google nezmiňuje více o té druhé polovině chyb práce s pamětí. Možná v tom budou i jednodušší implementační chyby jako buffer overflow – tipoval bych, že spíše staršího data a nejspíš ne úplně učebnicové případy, které by zachytila statická analýza.

Jenže Vaše prohlášení "podle mne je to bezpečné" je maximum, čeho je v C++ teoreticky možné dosáhnout, a to prostě nestačí.

V tom je právě ten problém, každý si myslí, že píše bezpečně a nelze to jinak posoudit než důvěrou v tazatele, to je málo.

Pokud se podívám na tvůj kód, hodně zpozorním, máš tam spousty fixe-sized array, u kterých nekontroluješ přetečení, stačí malá nepozornost a právě problém, o kterém je článek, je na světě.

Tenhle kód při parsování jsonu je zranitelný na buffer overflow, https://github.com/ondra-novak/mmbot/blob/master/src/brokers/httpjson.cpp#L61-L68, možná pro tvoje účely to je OK, u chromium by to byla kardinální chyba.

Poté používáš funkce jako sprintf (https://github.com/ondra-novak/mmbot/blob/master/src/trainer/main.cpp#L884) nebo sscanf (https://github.com/ondra-novak/mmbot/blob/master/src/brokers/isotime.h#L26) bez ošetření buffer overflow. Jasně v tomhle kódu to je třeba teď bezpečné, ale za nějakou dobu tam někdo udělá jinou úpravu a bezpečnostní chyba je na světě (podvrhnout chybný čas aplikaci lze třeba relativně dobře). Tyhle věci musíš automaticky ošetřovat a nespoléhat, že je někdo jiný použije dobře.

Na řádkách L61-L68 buffer overflow není. Data se cpou o ostringstreamu a limitem je maximalne velikost paměti - cpou se po blocich

Použití sprintf a sscanf by se dalo jistě nahradit lepším řešením, ale v daném kontextu ano bylo rychlejší pro implementaci a i troufnu si říct i pro performance.

Se závěrem nesouhlasím. Pokud někdo přebírá kód formou copy&paste - je zodpovědný za jeho obsah, jako by ho napsal sám, svými prsty.

Pokud jej přebírá jako knihovnu, je zodpovědnost na autorovi knihovny. Také je potřeba, aby dotyčný definoval kde se knihovna hodí - stejně jako si koupíte v reálném obchodě zařízení, taky je napsáno, že se nesmí používat tu a tam a že je k úrčitému účelu.

Nespoléhal bych se slepě na překladač s tím, že musí zaručit bezpečnost. Nemusí. Pokud tomu půjde naproti bezva, ale nemusí.

C/C++ může stále mít význam, pokud chci napsat něco pekelně rychlého, ale na bezpečnosti mi nezáleží -- třeba fyzikální simulaci pro interní použití. V takovém případě si člověk rád ušetří dodatečný overhead bezpečnějších jazyků typu Rust, ať už v nárocích na vývojáře (boj s borrow checkerem), tak potenciálně runtime overhead (zrovna u Rustu obecně moc není, ale třeba u jazyků postavených na VM).

Jazyk je jenom nástroj. Nemá žádnou citovou ani kulturní hodnotu, stejně jako ji nemá šroubovák. C má dosud své místo a své výhody, C++ byl odjakživa hrozný paskvil. Doopravdy neumře nikdy stejně jako neumře COBOL, ale jak se člověk jednou zbaví Baby Duck Syndromu a ocení výhody modernějších jazyků (v případě C++ tou modernější náhradou může být D, Rust, případně C# nebo i Python, podle typu aplikace), už je návrat k C++ těžko představitelný.

To Servo psané v Rustu se začíná jevit jako dost dobrý krok Mozilly. Snad i díky němu věřím, že se Gecko (s postupnou integrací komponent z Serva) zmodernizuje do dobrého prohlížeče.

Jako programátor C++ nemám s pamětí problém. Chytré pointery jsou jen začátek.

Chromium ale má moře kódu v C. nebo v C++ který wrapuje C funkcionalitu

Nebo v C++ s chytrými pointery, které prostě nefungují. Kód ve výlučně "moderním" C++ s chytrými pointery a všemi ostatními vylepšeními, plný leaků, use after free a pádů, Vám kdykoli napíšu na požádání.

Áno, to se Vám nepochybně podaří, ale problém není ani tak v tom, že by C++ bylo špatné, ale v tom, že je to jazyk historický postavený na jiných programátorských paradigmatech dané doby. Před 20 lety byl považován za dobrého programátora ten, který uměl problémy s pamětí správně ošetřit. Dnes se řekne: „to není špatný programátor, že si nepohlídal všechny pointery“ … „to je tím, že jazyk je špatný“. Je to z toho důvodu, že jiné jazyky to hlídají za programátora, a tím se eliminovalo jedno z rizik programování (jeden z potřebných skillů programátora).

Navíc C++ při je ho postupné modernizaci se procházelo od konceptu C ke knihovně C++ s několika málo změnami po moderní jazyk (rok 2011+). Avšak s ohledem na zpětnou kompatibilitu se zachovaly možnosti psát „po staru“, a programátor má mnoho volnosti prasit dohromady konstrukty ze starého C, starého C++ a moderního C++.

To všechno dělá z C++ nebezpečný jazyk, a pokud chcete programátory donutit psát bezpečně, což se v praxi jaksi hodí, tak jim musíte C++ v současné formě zakázat. Je to smutné, ale je to tak, C/C++ umožňuje mnoho volnosti, ale bohužel ta volnost vede programátory ke špatnému používání jazyka a výsledkem jsou chyby.

Řešením je jedině omezit se (to lze vymáhat v analýzou kódu a v budoucnu lze předpokládat, že pokud C++ neumře, tak bude možné bezpečné standardy kódování vymáhat v lintu nebo i přímo kompileru) na moderní konstrukty (např. dle C++ Core Guidelines), které byly vymyšleny (a doplněny do C++) za tím účelem, aby se právě tyto chyby eliminovaly, z C++ se tak může stát jazyk podobný jiným moderním jazykům (ostatně nemálo těch konstruktů (C++11 až C++20) bylo převzato z jiných jazyků ve kterých se osvědčily).

Ano, C++ patří k těm jazykům, pro které platí „jaké si to uděláš, takové to máš“. Dalo by se říct, že to není programovací jazyk, ale nástroj, kterým si každý může vyrobit svůj vlastní programovací jazyk. Podle toho pak také vypadají diskuse, kde to vypadá, jako by každý psal o jiném jazyku – jenže ono to tak vlastně je. Problém je to právě u těch komplexních projektů, kde se potká spousta takových jazyků, všechny se syntaxí C++. Pak hodně záleží na tom, zda se těm schopnějším podaří vnutit ten svůj jazyk celému projektu.

Jenomže ono to není jenom o tom, že se musí používat moderní konstrukty (nemluvně o tom, že řada existujících knihoven včetně současného iostream prostě jako parametry bere char*). Je to o tom, že v C++ neexistuje lifetime analýza. Když například pořebuji v nějaké třídě mít referenci na jiný objekt, jsou v podstatě jenom dvě možnosti:

- buďto pracuji s nějakým unique_ptr nebo shared_ptr, což znamená, že tím vynucuji, jaký typ pointeru mi má volací kód předat, což hlavně u knihoven je problém;

- nebo přijmu referenci& (nebo pointer *) a v tu chvíli je po všem, protože v C++ není možné zajistit, že taková reference nepřežije objekt, na který ukazuje, že nemůže být nulová, nebo že nebude docházet k nekontrolovaným mutacím atd.

C++ je prostě děravé a je to jednak proto, že vzniklo v době, kdy pokročilejší metody statické analýzy prakticky neexistovaly, a jednak proto, že jeho filozofie vždycky byla implementovat všechny myslitelné featury a s problémy se potýkat "potom". V důsledku to vede i k takovým věcem, že najednou (pokud si pamatuju, tak v C++11) museli zavést novou alternativní syntaxi deklarace funkcí, protože s tou starou se jazyk stal neparsovatelný.

Jistě, že za pomocí analyzátorů a rigidní disciplíny je možné řadě problémů předejít, ale to není omluva a neznamená to, že C++ je vlastně dobré. Jestliže staré C++ bylo minové pole, tak moderní C++ je pořád minové pole, akorát je tam cedule "pozor miny". Rozhodně nevidím důvod, proč by měl někdo záměrně chtít jít zrovna tudy, pokud má jinou možnost.

26. 5. 2020, 09:20 editováno autorem komentáře

Ano, zatímco v jednom jazyce musíte rozhodnout jestli tam bude reference (příjemce odmítá vlastnit objekt) nebo chytrý pointer (příjemce chce vlastnit objekt) v jiném jazyce vám tam vnutí ten pointer (java) a programátor o tom vlastně nemusí přemýšlet.

Otázkou je, co je lepší. Tohle hodnotit nebudu

Před 20 lety byl považován za dobrého programátora ten, který uměl problémy s pamětí správně ošetřit.

Problém spatřuju v tom, že spoustu známých bezpečnostních chyb způsobili dobří programátoři. Možná ne tak dobří, aby splnili tuhle definici, ale dost dobří na to, aby se nedali snadno nahradit. A dost dobří na to, aby je drtivá většina zdejších čtenářů, ne-li všichni, respektovala. Protože chyby se stávají a nedají se eliminovat dodržením jednoduchých pravidel typu strcpy/strncp­y/strlcpy.

On je tu jeste dalsi dulezity aspekt.

Dejme tomu ze jsem buh, co chyby v pointerech nedela, ani pri refaktoricazo apod, protoze mam hlavu jak patraci balon.

Otazka zni, jestli je stejny buh i ten Ind, co psal knihovnu pro odesilani SNMP trapu, kterou linkuju. Nebo libovoilnou jinou knihovnu, treba OpenSSL s jeho Heartbleed.

Ale ty přece také používáš C++ kód, který wrappuje C, který není bezpečný na všech platformách a vždy, např. používáš std::string tmpfile, který má problémy se staršími systémy, viz https://cwe.mitre.org/data/definitions/377.html.

U C++/C vůbec nejde o to, že umíš dobře psát, ale o to, že to dobře se nedá snadno ověřit a prokázat, vznikají chyby kombinací různých nepředvídatelných situací a máš tam jednu past vedle pasti.

Skvele, takze chrome bude teraz 5-krat pomalsi a zrat 10-krat tolko pamete.

A na to jsi přišel jak?

Zaplatí prostě daň za bezpečnost.

Pokud se na objekt odkazuje několik objektů a chyba je v to, že jeden jim ho mění pod rukama, tak se to fixne vytvořením kopie (asi jako přiřazení proměnné v Erlangu). Vytvoření kopie chce paměť a čas.

Pokud odkaz přežije objekt, tak je dvojí obrana - neukazovat na objekt, ale při předání odkazu si ho naklonovat. Klon potřebuje paměť a kopírování (jedno, jestli se motá v cyklu, nebo čeká na DMA). Nebo počítat reference, občas se zastavit a projet to garbage collectorem (GC, který nezaměstná CPU, jsem ještě neviděl). GC je zátěž navíc, kolikrát projede všechny objekty v paměti bez toho, že by něco mazal...

No a pokud chci mít jistotu, že se někde něco nedomrví, tak nas..ru aserce úplně na všechno a ve všech funkcích. Už ti někdo řekl, že podmíněný skok je nejdražší instrukce kvůli zahazování pipeline? A že pokud budeš odskakovat jenom při chybě, otrávíš si branch prediktor?

Kde vidíš zachování nebo snížení spotřeby paměti/CPU?
A - tadá - takzvaně "bezpečnější jazyk" to řeší úplně stejně, akorát se to nemusí psát explicitně, takže ubude překlepů nebo opomenutí. Výkon pude tak jako tak do kopru.

Možná by pro začátek stačilo nedělat "objekty".

V Rustu můžete mít víc odkazů na jeden objekt a kompilátor zajistí bezpečnost s nulovou režií v čase běhu.

Bezpečný jazyk ulehčuje agresivní optimalizace, C/C++ vede k defenzivnímu přístupu.

Mám pocit, že lidi co tu píšou pesimisticky o C++ v něm kdysi možná dělali, ale teď už nemají vůbec přehled. Nedávno byl v Praze schválen nový standard C++20 s největší účastí co kdy byla. Nová verze je každé 3 roky. Jak gcc, clang, tak Visual Studio adpotují nové věci už v průběhu návrhu nového standardu. Vývoj jde naopak rychleji než kdy předtím.

https://www.reddit.com/r/cpp/comments/f47x4o/202002_prague_iso_c_committee_trip_report_c20_is/

Nevypořádal ses s konkrétními připomínkami v diskusi, zejména:

1. Složitost C++, které si i přes další a další revize všechen ten balast z minula nese s sebou.
2. Absence lifetime analýzy, která vede k chybám i v moderním C++.
3. Problémy s parsováním deklarací funkcí vyřešené alternativní syntaxí s klíčovým slovem auto. A dodávám já - celkový syntaktický horor oproti různým konkurenčním jazykům, byť je vidět, že autoři C++ dělají co mohou.

Určitě máš pravdu, že nové verze jsou o něčem jiném a konkrétně třeba zavedení modulů (konečně!) je velký posun kupředu. Jak se ale v moderním C++ formátují řetězce? V Novákově repozitáři, který zde odkazuje, vidím třeba

var1 + " - " + var2 + ": " + var3

V jiném příkladu zde v diskusi vidím nechvalně známé

cout << "Hello world" << endl;

Dost hrůza. Už na tohle existuje něco rozumného nebo se to aspoň chystá?

26. 5. 2020, 12:29 editováno autorem komentáře

1) To je základní vlastnost jazyka se kterou musí člověk počítat. Zpětná kompatibilita je pro velkou část uživatelů C++ zásadní. Maximálně se uvažuje o nějakých epochách jako v Rustu.
2) Ano není součástí C++. Už jen kvůli bodu jedna to ani není možné. To by znamenalo udělat nový jazyk. Pro statickou i dynamickou analýzu je plno nástrojů součástí všech hlavních překladačů. A zrovna lifetime je něco co v moderním C++ člověk prakticky neřeší.
3) Nevím přesně o jaké problémy s parsováním se jedná. Nové verze je zejména pro automatickou detekci návratové hodnoty. Používá se zejména pro zjišťování
návratové hodnoty z šablonových parametrů. Pokud si tam dáte konkrétní typ, tak to už je na vás. C++ vás neomezuje.
4) Je dobře že se ptáte zrovna na formátování. V C++ 20 je nová knihovna format.
https://en.cppreference.com/w/cpp/utility/format

1. Ano, udělejte to!

2. Tak dík, zůstanu u Rustu.

3. Ano, jedná se o šablonové parametry - podle toho, co jsem četl v nějakém článku. Každopádně to řešení působí trochu zvláštně.

4. Přesně tohle to chtělo, dík za odkaz. Formátování tedy škrtám.

1) Nemyslím si, že k tomu v dohledné době dojde. Nikdo nikoho nenutí psát pro C++ překladač v C, a přitom to v podstatě jde. Je to v mnoha ohledech nevýhoda, ale v současné době, kdy se klidně programovací jazyk v nějaké verzi zažízne a hotovo, to je možná i výhoda. Dá se postupně psát nové věci v novém standardu, a není nutné hned vše přepisovat do nového.
2) Není zač.
3) Toto řešení se podle mě zvolilo, protože byla požadována nová vlastnost, která se starou syntaxí snad ani nešla udělat. Čili se muselo vytvořit něco nového. Navíc to stejně funguje u lambda funkcí, kde návratovou hodnotu ani jinak určit nelze.

Souhlasím, že toho syntaktického balastu je hodně, ale to by se muselo jinak zavádět ještě mnohem více klíčových slov, a nebo odříznout tu zpětnou kompatibilitu. V C++ 20 je např. nová syntaxe pro koncepty, takže velikost balastu se sice sníží, ale člověk aby se učil novou syntaxi :D. Ale nikdo vás nenutí k nové syntaxi, díky kompatibilitě člověk může dál psát ten balast :D.

V moderním C++ se řetězce formátují pomocí https://en.cppreference.com/w/cpp/utility/format

Pro starší c++ se dá použít takřka identická knihovna fmt.

a zase mám s tou novou vychytávkou trochu problémy. Já třeba používám referenci indexem při formátování.

logDebug("V domu je $1 stenata a $2 kotata", cstenat, ckotat)

Pokud někdo bude chtít hlášku přeložit a přehodit štěňata a koťata, určitě zvládne přehodit čísla u $

std::format("V domu je {} stenata a {} kotata", cstenat, ckotat)

(jen příklad, zapomeňme nyní na problémy s češtinou, číslovky a pády)

RTFM : std::format("V domu je {0} stenata a {1} kotata", cstenat, ckotat) to umí taky

26. 5. 2020, 18:36 editováno autorem komentáře

> Nová verze je každé 3 roky

Ještě je dobré dodat, že polovina novinek jsou rovnáky na vohejbáky, čímž je krásně ukázáno, jaký bordel v tom jazyku je (tedy spíš je to špatnou koncepcí) a kolik dalšího bordelu se s každou verzí přidává. Nemluvě o tom, že ty nové konstrukty nejsou ortogonální, čímž se programátorské peklo nezadržitelně prohřívá...

V každém dlouhodobě vyvíjeném jazyce časem přibývají rovnáky a ohýbáky na věci, které se v minulosti nenavrhly dobře.

Řešit to formou - naučím se nový jazyk - který časem stejně bude plný rovnáků a ohýbáků - není řešení.

(nebavme se o C++, vzpomenu si na Javu, nebo na Python, ale i ten módní Rust už má v sobě dost rovnáků, konečně celý Rust mi přijde jako jeden velký rovnák a ohýbák na C ve stylu "C++ je fuj, narovnejme C)

Celý Rust mi přijde jako jeden velký rovnák a ohýbák na C ve stylu "C++ je fuj, narovnejme C

Vyprávěj, přeháněj.

[Karell]
"Ještě je dobré dodat, že polovina novinek jsou rovnáky na vohejbáky, čímž je krásně ukázáno, jaký bordel v tom jazyku je (tedy spíš je to špatnou koncepcí) a kolik dalšího bordelu se s každou verzí přidává. "

Coz lze s uspechem tvrdit o kadem jazyce, notabene pokud se vyvviji.

"Tvrdit s úspěchem" lze cokoli. Ale zkus srovnat C++ s nějakým konkrétním jiným jazykem nebo aspoň dvěma, třemi, ať to zasadíš do smysluplného kontextu.