ChakraCore od Microsoftu na GitHubu

V prosinci Microsoft oznámil (zprávička), že v lednu uvolní ChakraCore, tj. jádro svého javascriptového enginu Chakra používaného v prohlížeči Edge, jako open source. Dnes se tak stalo. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.

13.1.2016 22:44 | Ladislav Hagara | Zajímavý software

Komentáře

[Jardik]

Hahaha

typedef uint8 Char;
typedef uint8 UChar;
static const int CharWidth = sizeof(char) * 8;

Proč? sizeof(char) je vždy 1! Pan vývojář se snažil být chytrý a utvořit portabilní kód a dopustil se neznalosti ... a kousek za tím udělá *8, kde jeho pokus o portabilní kousek kódu zhatí nepoužitím CHAR_BIT a zamezí spuštění javascriptového enginu na takových platformách jako Texas Instruments C54x. Jeden by mohl říct, že přece uint8_t na takové platformě ale neexistuje ... to je pravda, ale co je uint8, to nevím, třeba je to nějaká náhražka uint_least8_t, nechce se mi hledat...

static inline CharCount OSB(const Char* ph, const Char* pl)
{
    Assert(ph >= pl && ph - pl <= MaxCharCount);
    return (CharCount)(ph - pl);
}

Aáá, tohle je hodně nebezpečné, protože výsledek odčítání pointerů je znaménkový typ, na který existuje typedef ptrdiff_t, na některých platformách ee, protože jakmile je rozdíl pointerů velký, máme tu UB. Takovými chybami je ale ostatně prošpekována třeba i glibc. Takový musl libc kvůli tomu udělal omezení, že malloc pro více jak PTRDIFF_MAX selže s ENOMEM, a zakazují programátory používat velké datové struktury. A dokonce i GCC a clang jsou na tom špatně, mají pointery a element indexy (llvm) jako čísla se znaménkem. Fůj.

[zer0]

a zamezí spuštění javascriptového enginu na takových platformách jako Texas Instruments C54x

No za to ho určitě čeká vyhazov

[Lol Phirae]

No za to ho určitě čeká vyhazov

[Michal Kubeček]

Jestli tohle jsou nejvážnější problémy, jaké tam mají, tak mají můj upřímný obdiv.

[Jardík]

To já nevím, já kouknul jenom do pár souborů, nemám náladu pročítat celý zdroják.

[Michal Kubeček]

Na mne to tak nějak působilo, že jste je chtěl rychle a bez námahy zesměšnit, tak jste si našel nějakou drobnost, po které byste se mohl vozit podle hesla "kdo chce psa bít…". Jinak byste totiž např. během pár desítek sekund zjistil, že uint8 je typ, který si sami definují v jiném hlavičkovém souboru, a spíš se ptal na __int8, což je asi nějaký nativní typ specifický pro MSVC.

[Xerces]

Na mne to tak nějak působilo, že jste je chtěl rychle a bez námahy zesměšnit ... tak to je u MS asi zbytečná snaha. To zvládnou s přehledem sami.

[Ivorne]

To sizeof(char)*8 je fakt docela vtipný. Autor se snaží být super korektní pomocí sizeof(char), což ani není nutné, a přitom tu super korektnost hned zase zkazí.

[Jardík]

To určitě ne. Já upozorňuji na programátorské chyby a předpoklady, které nacházím poměrně často v mnoha projektech. Rozdíl ukazatelů je velmi např. velmi nebezpečná věc, v mnoha kompilátorech je implementována vyloženě špatně a nikdo se ji nesnaží opravit (např. protože "overhead"). V mnoha knihovnách vidím věci jako size_t length = end - start, přitom výsledek je znaménkový a může být špatný. Vemte si třeba pole znaků o velikosti 3GB na x86 platformě, start je třeba adresa 1 a konec 3G+1, ptrdiff_t je v případě gcc/glibc na této platformě 32bit znaménkový typ, který těžko pojme hodnotu 3G a podle standardu je to tedy UB (protože výsledek rozdílu pointerů to nepojme). Taky občas narazím na případy if (start + len > end) nebo kde se snaží zkomponovat kontrolu přetečení if (start + len > end || start + len < start), kterou kompilátor zoptimalizuje a vyhodí pryč, protože předpoklad je, že pokud k adrese objektu připočtu jeho maximální velikost, nemůžu dostat adresu menší (v podstatě stejně, jako když máte UB s přičítáním znaménkových typů, kdy si myslíte, že může dojít k overflow a kompilátor vaši kontrolu vyhodí, protože je to UB, nemělo by to nastat a tak není třeba kontrolovat). Programy se pak záhadně rozbíjí při práci s trochu většími daty. Problémy jsou to bezpečnostní, protože jsou zneužitelné. UB třeba může vést ke smazání celého disku.

[Ovocníček]

No jo, ale když to takhle kritizuješ z křesla místo bugreportu, tak můžeš ignorovat některé skutečnosti, které autoři ví a ty zatím ne. Spousta věcí které se nově příchozímu inteligentovi zadjí být pitomé má svoje promyšlené důvody, takže to někdy chce opatrnost. Ale neříkám, že tady nemůžeš mít pravdu, to holt netuším.

[Jardík]

Bugreporty, třeba v GCC, glibc i musl, dávno existují, popř. témata v diskusních skupinách, kde se vyjadřují i autoři. Prostě jim nestojí za to podporovat velké objekty, a když si jej náhodou vytvoříte třeba přes mmap() (přímo syscallem a né wrapperem v libc, který vás třeba, jako v musl libc, omezuje na PTRDIFF_MAX), tak vám nic nezajišťuje funkčnost libc funkcí, které s takovým objektem budou následně pracovat. Nedávno se třeba řešilo téma "Possible infinite loop in qsort()" v musl libc, což je následek takových různých předpokladů a umělých a někdy hlavně i nedokumentovaných omezení algoritmů. Ostatně právě i tam je hezký příklad, který se také často vyskytuje:

char *match = strstr (arg, str);
size_t to_len = match - arg;

Je to UB, když arg je hodně dlouhý a str je někde u konce, máte třeba 3,5G - 1G = 2,5G a to třeba na na x86 neprojde, protože PTRDIFF_MAX je menší. No a k tomu pak ještě ten implicitní typecast z ptrdiff_t na size_t, který problém hezky zamaskuje a utvoří nám kladné číselko, pokud se nám díky UB předtím nespálil procesor. (x86 a dané velikosti jsou příklad, obyčejně mě x86 nezajímá, ale platí to pro všechny platformy obecně, při správně velkých velikostech).

Podobný problém je pak v C++ třeba u iterátorů a některých (třeba ručně implementovaných) kontejnerů, kde není funkce typu max_size(), díky čemuž pak nemůžete předpokládat, že nenastane UB při rozdílech iterátorů. Koukněte třeba do kontejnerů, co si MS (někdy prostě zbytečně, protože nechcou použít altarnativu ze standardní knihovny) implementuje, nebo InternalString apod. splácaniny, co mají všude rouzdílné skryté a nedokumentované limity (např. INT_MAX, UINT_MAX atd), které ještě jsou všude rozdílné a nemůžete si tak ničím být jistí. A ještě náhodné zaměňování typů long a int, která na windows x32 i x64 mají náhodou stejnou velikost.

[Michal Kubeček]

Na to nelze než zopakovat, co jsem napsal ráno v 9:19.

[Jardík]

Cílem ale není zesměšnit MS, ale ukázat ostatním, že takové chyby (které nepovažuji za bezvýznamné, hlavně u aplikací typu webový prohlížeč) se vyskytují a né jen u MS, ale i jinde. Někdo si to třeba vezme k srdci a až bude psát svůj projekt, bude pamatovat na moje hlody a dá si na to pozor, třeba jen proto, aby Jardík neměl blbý řeči. A nebo taky ne.

[Michal Kubeček]

Nebo se raději zamyslí nad tím, jestli je reálné, aby pole, nad kterým provádí pointerovou aritmetiku, mělo na 32-bitové architektuře více než dvě miliardy prvků.

[Jardík]

Ano, je. A ve windows je např. nějaká ta funkcionalita na remapování virtuální paměti, jak jen se to jmenuje ... v podstatě si i 32bit aplikace může adresovat hodně z celkové fyzické paměti a přepínat si je, aby se jí to mapovalo do její virtuální paměti, podle toho s čím zrovna potřebuje pracovat. Ale ta architektura byla příklad, klidně si zaměňte za jinou (x64 asi ne, tam je tuším limit nějakých použitelných 48 bitů).

[Sid]

to stale nemeni podstatu odpovede nad tebou. Clovek co potrebuje 2miliardove pole by zjavne asi dospel k tomu aby to prelozil na 64bit, nemyslis? Ale ok, cim menej miest kde sa moze nieco pokazit tym lepsie, len by to malo mat mieru.

[deda.jabko]

Jmenuje se to AWE a porad se nedostanes mimo ty dve giga, co ma proces pridelene, takze se to neprojevi.

[Jardík]

Proč se nedostanu mimo 2 giga? Je tam nějakej přepínač pro kernel, který mi dovolí 3GB, ale o to tu nejde.

[Odin1918]

aby Jardík neměl blbý řeči

A najde si jardik divku, aby nemel odin blbe reci?

[Odin1918]

Uz mas praci? Divku? Samostatne bydleni?

[Jardík]

Nemám, nemám a taky nemám. Za to mám teď problémy se štítnou žlázou a erekcí.

[pushkin]

Ať si ho strčí coby čípek!

[Karel]

sám sobě si čípek strč