Portál AbcLinuxu, 12. května 2025 18:37
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.
a zamezí spuštění javascriptového enginu na takových platformách jako Texas Instruments C54xNo za to ho určitě čeká vyhazov
No za to ho určitě čeká vyhazov
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.
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.
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.
aby Jardík neměl blbý řečiA najde si jardik divku, aby nemel odin blbe reci?
14.1.2016 08:15
pushkin | skóre: 43
| blog: FluxBlog
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.