Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
int main() {
setlocale(LC_ALL,"");
wchar_t myChar1 = L'Ω';
wchar_t myChar2 = 0x2126; // hexadecimal encoding of char Ω using UTF-16
wchar_t myChar3 = L'\xe2\x84\xa6';
wprintf(L"%lc \n", myChar1);
wprintf(L"%lc \n", myChar2);
wprintf(L"%lc \n", myChar3);
return 0;
}
Zdroják je na disku uložen v souboru jako UTF-8, tj. znak 'Ω' je v něm jako 0xe2 0x84 0xa6. Ovšem pokud ho chci zapsat v C jako posloupnost bytů tak musím přes UTF-16 (\u2126), já bych ho chtěl ale zapsat jako UTF-8, jako posloupnost těch 3 bytů myChar3.
Z mého pohledu se hodnota u myChar1 a myChar3 zdá stejná (jen trochu jinak zapsaná), ale ve výsledku není, poslední wprintf vypíše znak '¦', tj. \u00a6 neboli UTF-8 0xC2 0xA6.
No jsem z toho nějakej zblblej, používám gcc version 4.6.1 20110908 a glibc-2.14-5.x86_64 :D
Když si v bashi dám echo -e "\xe2\x84\xa6\u2126", tak to na obrazovku normálně vypíše ΩΩ.
wchar_t není UTF-8.
UTF-8 je representace znaků Unicode pomocí různě dlouhých sekvencí bajtů.
wchar_t je nějaký blíže nespecifikovaný platformově závislý vícebytový typ v C. Na MS Windows 16bitový integer (representující UCS-2), na Unixu spíš 32bitový integer (representující UCS-4), taky to ale klidně může být něco ještě podivnějšího, a Unicode Consortium nedoporučuje to používat kvůli přenositelnosti.
Takže běžnější (alespoň na Uninxu; na MS Windows platformová závislost málokoho trápí, když jejich veškerá platforma je MS Windows) je represntovat Unicode řetězce pomocí char v UTF-8, přičemž potom samozřejmě je rozdíl mezi znaky a bajty, protože znak může být více bajtů. Tvoje oblíbená knihovna/framework určitě má funkce pro práci s UTF-8 kódovanými řetězci, tudíž zapisuješ zdroják přímo v UTF-8 (vyžaduje, aby 8bitové znaky bral kompilátor, dnes už nebývá problém) a používáš příslušné UTF-8 (ne wide-char!) funkce.
mbsrtowcs() a wcsrtombs(), v C++ se přiřadí locale I/O streamu (metoda imbue()).
char * v UTF-8 – tak jak to dostaneš, tak to vypíšeš.
Řešit to musíš až v okamžiku, kdy tě zajímá, kolik místa to zabere na obrazovce (strlen() nestačí) nebo pokud chceš seřadit seznam (strcmp() nestačí), případně zkracovat řetězce (abys nerozpůlil znak).
Tiskni
Sdílej: