Linux ve Scratchi. Ne Linux v linuxové distribuci Linux From Scratch ale Linux bežící v emulátoru procesoru RISC-V ve vizuálním programovacím jazyce Scratch.
Dnes ve 12 hodin začal další ročník CTF (Capture the Flag) soutěže The Catch: "Tentokrát nás kolegové z Forenzní laboratoře zavedou na loď plnou sofistikovaných síťových technologiích, kde soutěžící budou muset zvládnout náročné úkoly. Loď nese jméno našeho skvělého kolegy Josefa Vericha – síťového guru. Tradičně se soutěž koná v říjnu – měsíci kybernetické bezpečnosti."
Konference LinuxDays 2023 proběhne již tento víkend 7. a 8. října v prostorách Fakulty informačních technologií Českého vysokého učení v Praze (FIT ČVUT). Na programu je spousta zajímavých přednášek a workshopů.
Netflix v pátek 29. září odeslal poslední film na DVD (YouTube). Společnost dnes známá jako streamovací služba začala před 25 lety jako půjčovna filmů na DVD. Zákazník si DVD objednal na webových stránkách, odesláno mu ale bylo klasickou poštou. Po zhlédnutí jej vložil do obálky a poslal zpět.
Zero Day Initiative zveřejnila informace o 6 bezpečnostních chybách (1, 2, 3, 4, 5, 6) v MTA Exim. Nejvážnější z nich CVE-2023-42115 má CVSS 9.8. Na opravě chyb se pracuje.
Knihovna libvpx byla vydána ve verzi 1.13.1. Řešena je kritická bezpečnostní chyba CVE-2023-5217 (heap buffer overflow in vp8 encoding). Chyba je již opravena také v Chrome / Chromium 117.0.5938.132 a Firefoxu 118.0.1.
Balíček kmod s nástroji pro práci s linuxovými moduly byl vydán ve verzi 31. Nově umí modprobe zavést modul nacházející se v libovolném adresáři (# modprobe ./drivers/gpu/drm/i915/i915.ko).
Adventura Trüberbrook je na portále GOG.com zdarma, akce trvá do 2. října.
Sound Open Firmware, projekt Linux Foundation, open source audio DSP firmware a SDK, byl vydán ve verzi 2.7.0. Z novinek lze vypíchnout podporu platformy AMD Van Gogh.
Richard Stallman v den oslav 40. výročí GNU oznámil, že má rakovinu (YouTube).
Nadšený programátor a občasný pisálek.
void Trim(char *str) {
int zleva; //kolik bílých znaků zleva oříznu
for (zleva = 0; str[zleva] != '\0'; zleva++) {
if (str[zleva] > ' ') break;
}
int i; //zkopíruju zbytek řetězce
for (i = 0; str[i+zleva] != '\0'; i++) {
str[i] = str[i+zleva];
}
//najdu konec řetězce
for (i--; i >= 0 && str[i] <= ' '; i--);
str[i+1] = '\0'; //a oříznu
}
Celkem krátký kód, poměrně lehký, skoro školní úloha. Nicméně, tato funkce nepracuje správně if (str[zleva] > ' ')
a jdou uřezány společně s bílými znaky. Je to trochu od jazyka C/C++ zrada; sice je znaménkový typ konzistentní se standardní „znaménkovostí“ jiných typů, ale u řetězců toto nemá význam; neumím si představit, kdy bych využil, že ASCII >= 128 je reprezentováno zápornými hodnotami. Naopak je mnoho případů, kdy dochází k chybám a podivným nelogičnostem (viz např. tato ukázka). V Javě jsou třeba všechny typy striktně znaménkové, ale typ char je jediný neznaménkový (16bitový). Taktéž i jiné jazyky nikdy neberou znak jako záporné číslo.
Druhou chybou je použití typu int k indexování. Typ int je 4bajtový (nebo 2bajtový v 16bitovém prostředí) a nehodí se tak pro adresaci paměti. K adresaci paměti je vhodné použít typ size_t (neznaménkový) nebo ptrdiff_t (znaménkový). Tyto typy tak veliké, jak veliký je ukazatel; na 32bitovém mají 4 bajty, na 64bitovým 8 bajtů. V tomto případě by se program v 64bitovém prostředí zacyklil na prvním cyklu při 2 GiB dlouhém řetězci. Na 32bitovém prostředí by pak neořízl řetězec zprava (hned by vyskočil z třetí podmínky).
Tiskni
Sdílej:
konkrétně se zacyklí i na stringu delším než 2 GiB, a tedy i na 32bitOpravdu se rozbije i na 32bit systemu? Nejsem si teda presne jist, jak se chova pointerova arimetrika pri preteceni, ale tipoval bych ze to vezme modulo 2^32, takze se to bude prakticky chovat jako by byl index unsigned.
str[i+1] = '\0';
je out of bounds pro prazdny retezec a taky to nefunguje pro retezce ktere jsou jenom z bilych znaku
Netusim jestli to je jedna nebo jsou to dve chyby.
void Trim(char **str)
?
void trim(char *str) { char *begin = str, *end; while ((unsigned char)*begin <= ' ' && *begin != '\0') begin++; end = begin + strlen(begin); while ((unsigned char)*end <= ' ' && end > begin) end--; memmove(str, begin, end - begin + 1); str[end - begin + 1] = '\0'; }
Přiznávám se bez mučení, že úvahu "považujme za bílý znak cokoli s kódem menším nebo rovným 32" jsem bral za natolik nesmyslnou, že jsem si prostě místo toho testu v duchu dosadil isspace()
a chybu tudíž neodhalil, protože mne nenapadlo hledat chyták v podobě chybné implementace něčeho, co je samo o sobě chyba.
Mimochodem, určitě je podle normy char
znaménkový? Vždycky jsem měl za to, že je na implementaci, jestli bude char
totéž co signed char
nebo unsigned char
, a programátor by tudíž neměl předpokládat ani jedno.
Mimochodem, určitě je podle normy char znaménkový? Vždycky jsem měl za to, že je na implementaci, jestli bude char totéž co signed char nebo unsigned char, a programátor by tudíž neměl předpokládat ani jedno.C99 6.2.5 Types An object declared as type char is large enough to store any member of the basic execution character set. If a member of the *basic execution character set* is stored in a char object, its value is guaranteed to be nonnegative. If any *other character* is stored in a char object, the resulting value is *implementation-defined* but shall be within the range of values that can be represented in that type. 5.2.1 Character sets Both the basic source and basic execution character sets shall have the following members: the 26 uppercase letters of the Latin alphabet, the 26 lowercase letters of the Latin alphabet, the 10 decimal digits, 29 graphic characters (pozn. zavorky, carky apod.) .. tedy zakladni znaky lze predpokladat jako signed, ale vse ostatni je implementation-defined. Dulezite je, ze to chovani je arch dependent, treba x86 GNU/Linux je signed, ale ARM je unsigned apod. Viz: http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html Takze je vhodne bud kompilovat s -fsigned-char pokud trvate na tom, ze char ma nejake urcite znaminko. Jinak v kodu je vhodne pouzivat "char" jen tam kde se nepracuje se znaky, jinak striktne "unsigned char".
jsem si prostě místo toho testu v duchu dosadil isspace() a chybu tudíž neodhalilPozor, s
isspace()
vznikne velice podobná chyba – není ho totiž dovoleno volat se záporným argumentem.
Vždycky jsem měl za to, že je na implementaci, jestli bude char totéž co signed char nebo unsigned char, a programátor by tudíž neměl předpokládat ani jedno.Přesně tak.
Ze ß to vyrobilo SS? Jako z jednoho znaku dva?Pokud ano, tak to jednalo zcela podle standardu: UniCode (alespoň ve verzi 5.0, do které zrovna koukám) ve svých case mappings opravdu definuje, že 00DF (German es-zed) má jako upper case 0053 0053 (SS). A stejně se, tuším, chová i německý pravopis.