Názor k článku
Kolem 70 % vážných bezpečnostních chyb v Chromiu jsou chyby používání paměti od J ouda - Možná si nerozumíme (a možná nerozím já Vám...

  • Článek je starý, nové názory již nelze přidávat.
  • 27. 5. 2020 0:58

    J ouda (neregistrovaný)

    Možná si nerozumíme (a možná nerozím já Vám co píšete v rámci rustu, který neznám).
    Jde mi o zhruba následující, zcela hloupý, zjednodušený a neoptimalizovaný příklad. Mám server, přijme tcp connection, tomu naalokuje (na heapu) nějakou strukturu kterou strčím do nějakého seznamu, která obsahuje dejme tomu nějaké síťové detaily (socket, rcv a send buffer + head a tail na ně, nějakou stavovou proměnnou, případně nějakou vyšší abstrakci nad tím) plus string nickname. Celá ta veselost umí jen poslat někomu jinému zprávu, takže fajn, v rámci obsluhy vyparsuju co přišlo, udělám iteraci přes všechny connections a když sedí nick, tak tomu předám zprávu do send bufferu, zavolám write() a hotovo. (neřešme teď chyby, blocking etc., jde mi jen o datové struktury)

    No a pak si vymyslím featuru, že když se někdo odloguje, tak to má napsat všem, s kým si povídali. Takže mě napadne ke každému connection přihodit nějaký seznam, který _nějak_ (v céčku to budou pointery, v rustu nevím a tam směřuje onen dotaz) ukazuje na connections účastníků, které je třeba notifikovat.

    Tady kompiler nemá jak během compile time poznat živost (prostě objekt zmizí ve chvíli, kdy mu spadne tcp connection), a za běhu si nedovedu představit, jak by to (ať už automaticky nebo manuálně) mohl udělat bez přídavné režie, jak tu tvrdil předřečník. Kompiler můžu vygenerovat při zrušení reference automaticky decrementovat ref_count a při nule zavolat nějaký free()/dealloc() nebo jak se to jmenuje, ale jak psal předpředřečník zadarmo to není, nebo může jen dekrementovat referenci ale samotnou práci nechat na GC, celé to samozřejmě může co do taktů velmi zlevnit optimalizace překladu (proč inkrementovat ref_count když vím že ho hned zase dekrementuju, teda pokud to není multithread, ale to je jen detail a měli bysme podobnou diskusi kolem Arc), ale cena na paměť tam bude pořád (minimálně je to o sizeof(refcount) interně víc - to že v 99% RL aplikací na tom nesejde je věc druhá)

    Nebo jsem jen pochopil špatně, a reálně se v rustu podobné konstrukce dělají úplně jinak?