Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Příběh o tom, jak probíhá hledání a opravování chyby v autorovi dosud neznámém kódu, vypráví článek Opravujeme chyby v softwaru: inotify-tools. Krok za krokem stáhneme zdrojové kódy, přeložíme program a najdeme chybu – seznámíme se se základními postupy a nástroji pro diagnostiku chyb (verzovací systém, IDE, GNU Debugger, Kompare).
Tiskni Sdílej:
vim ~/.emacs
for ( i = 0; i < strlen(string); ++i ) {autoři si s optimalizacemi moc hlavu nedělali. Je to o vyhnutí se dynamické alokaci (o 4kB poli v lokální proměnné nemluvě). Na githubu mají dobrou opravu:
Do not double escape names. Fixes #36
S tou předčasnou optimalizací je trochu vedle. Jak je vidět z
Asi optimalizovali na obsazenou paměť ne na výkon, ale vyústilo to v to, že si paměť nechtěně přepisovali. To už mi snad přijde lepší, když tam bude únik paměti a program je nakonec sestřelen OOM killerem, než aby tam byla potenciálně bezpečnostní díra v podobě přetečení.
Samozřejmě ideál je to napsat tak, aby paměť neunikala, žralo jí to třeba o něco víc, ale konstantně, a bylo to bezpečné.
for ( i = 0; i < strlen(string); ++i ) {
Někdy se iteruje v opačném směru, k nule, což je trochu nezvyk, ale vlastně proč ne (pokud nezáleží na pořadí).
Nebo si klasicky uložit délku do proměnné.
o 4kB poli v lokální proměnné nemluvě
A jak by to mělo být správně? Alokovat dvojnásobek délky vstupu + uvozovky a nulový bajt? (jak navrhuje Kruci pod článkem) Nebo si alokovat nějakou dynamickou strukturu (jakou?) o velikosti tak 120 % vstupu, protože tam se to většinou vejde (a případně se ještě zvětší).
Do not double escape names. Fixes #36
Njn, chyba tam zůstala dál, jen se přestala projevovat.
for ( i = 0; i < strlen(string); ++i ) {Někdy se iteruje v opačném směru, k nule, což je trochu nezvyk, ale vlastně proč ne (pokud nezáleží na pořadí).
Nebo si klasicky uložit délku do proměnné.
Se zapnutými optimalizacemi by měl překladač toereticky uložit výsledek strlen(string)
do neviditelné automatické dočasné proměnné (popř. registru) a tu používat v cyklu, i když osobně bych na to raději nespoléhal - překladač musí mít jistotu, že vrácená hodnota je konstantní po celou dobu cyklu (tj. např. žádná pointerová aritmetika nebo předávání dalším funkcím, pokud není parametr const
), v opačném případě bude volat strlen(string)
při každém průchodu. Když už si někdo nechce zaplácávat zásobník, může proměnné použité k uchování délky řetězce nastavit jako register
a doufat, že to překladač pochopí správně a nebude jí alokovat žádnou paměť.
A i když iterovat "pozadu" je sice z algoritimického hlediska ekvivaltení iterování směrem vpřed, procesor, cache a paměti apod. jsou dělané na to, že se paměť čte směrem dopředu, ne odzadu (viz prefetch),
vsprintf()
, ta zajímavá funkce se jmenuje realloc()
. Na začátku si alokuješ těch 120% a když to nebude stačit, tak jen string = realloc(string, 2 * strlen(string))
a hotovo.
assert, že char *string náhodou nesměřuje někam do csv[]
Jenže pak by nešlo escapovat dvakrát. V tomto programu to asi není potřeba, ale jinak se to hodí (např. když chci někam vložit ukázku, jak vypadá escapovaný kód).
Pro mě má funkce prostě nějaký definiční obor a nějakou návratovou hodnotu a můžu ji zanořit třeba stokrát a pořád by měla fungovat. Proč by měla mít takové omezení jenom kvůli tomu, jaký jazyk jsem si pro implementaci vybral?
Dobré řešení asi je předávat ten buffer zvenku jako parametr a uvnitř nic nealokovat, ale pak to zase není funkce, ale spíš procedura.
Dobré řešení asi je předávat ten buffer zvenku jako parametr a uvnitř nic nealokovat, ale pak to zase není funkce, ale spíš procedura.Hlavne nevis jak velky ho budes potrebovat.
To je pravda – musím znát implementační detaily té funkce (od kterých bych měl normálně abstrahovat), abych určil maximální velikost výstupu. Jak to tedy napsat správně?
Na tom mi nesedí, že se paměť uvolňuje někde jinde, než kde byla alokována, resp. že je za to odpovědný někdo jiný a je to hodně náchylné k chybám. Ale asi je to v C normální…
BTW: dá se to nějak automaticky analyzovat nebo to musí všechno pročítat člověk? Odhalí nějaký nástroj tyhle problémy?