Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Hezky den
mam toto v c:
#include <netinet/in.h>
#define short unsigned int UWORD
a nekde toto:
UWORD i = 1;
i = htons(i); //htons pracuje in/out jen s UWORD, resp uint16_t
a KDEVELOP stale hlasi:
warning: conversion to 'short unsigned int' from 'int' may alter its value
Jak utnout tipec tomuto hlaseni, a ne zrovna tim ze vypnu kontroly typu?
Predem diky
Jarda
typedef.
#define short unsigned int UWORD#define UWORD short unsigned int
Sorry, ja se pri opisovani spletl, ma tam byt to co jste uvedl (viz nize), ale to problem neresi.
#define UWORD short unsigned int
rovnez to neresi ani toto:
i=(UWORD)htons((UWORD)i);
ci toto (ikdyz zrusim makro a i definuji jako uint16_t):
i=(uint16_t)htons((uint16_t)i);
i=(uint16_t)htons((uint16_t)i);Ty přetypování bych rozhodně vyhodil, protože proměnné odpovídají hlavičce funkce a takhle se to jenom zatemní.
Ja si to taky myslel, ale radsi se zeptam, protoze nikde neni duvod pouzivat int. No a ta hlaska nedava vice info, zda je to vuci leve hodnote ci parametru funkce. Takze dle odkazu off -Wconversion.
Asi to bude záviset na verzi gcc (nebo glibc). Právě jsem zkusil přesně ten původní kód:
#include <stdio.h>
#include <netinet/in.h>
#define UWORD short unsigned int
int main()
{
UWORD i = 1;
i = htons(i);
printf("%hu\n", i);
return 0;
}
a obešlo se to bez protestů i s '-Wall -Wextra'. Použil jsem gcc 4.3.2 a glibc 2.9.
Asi to bude záviset na verzi gcc (nebo glibc)Vypadá to tak:
gcc (GCC) 4.1.2 (Gentoo 4.1.2) řve, gcc (GCC) 4.4.0 20090526 (prerelease) je v pohodě.
U mě neřve ani jedna verze gcc, glibc 2.7-18:
gcc-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-13) gcc-3.4 (GCC) 3.4.6 (Debian 3.4.6-9) gcc-4.1 (GCC) 4.1.3 20080704 (prerelease) (Debian 4.1.2-25) gcc-4.2 (GCC) 4.2.4 (Debian 4.2.4-6) gcc-4.3 (Debian 4.3.2-1.1) 4.3.2
Hezky den
vsem diky ze se problemu venujete, tady davam info, kdy se to generuje na mem sw (stejny kod jak v prizpevku vyse):
tak to hlasi testwarning.c:16: warning: conversion to 'short unsigned int' from 'int' may alter its value. Vyradim-li prepinac -Wconversion, tak to hlaseni zmizi, na to vsak upozornil jiz v prispevku Vojtech Horky, takze pouziti tohoto prepinace je dvojsecne, sice oznaci mista, kde se pouzije implicitni pretypovani, ale oznaci varovanim i to kde jiste k pretypovani vubec nedochazi.
-Wconversion nestačí, ale když přidám optimalizaci, začne se ta hláška objevovat i u mne. Zřejmě to souvisí s tím, že ntohs() je definováno jinak při překladu s optimalizací a jinak bez ní. Ale teď bohužel nemám čas rozplétat všechny ty #ifdef-y v hlavičkových souborech.
Ja se dival na ten hlavickovy soubor, jednoznacne zneho vyplyva, ze hto... funkce jsou tam ruzne definovany podle optimalizace a zpusobu uschovy udaju v pameti, prakticky lze rici, ze pri max. optimalizaci by stacilo misto funkce pouzit inline assembler a to operaci bswap x (x znaci nejaky ten parametr) a kdo vi jak se to pak jevi prekladaci. Chci jen podotknout, ze htons neni jedine misto, kde se ten prepinac a warning objevuje, vybral jsem ji zcela nahodne.
netinet/in.h:
#ifdef __OPTIMIZE__ /* We can optimize calls to the conversion functions. Either nothing has to be done or we are using directly the byte-swapping functions which often can be inlined. */ # if __BYTE_ORDER == __BIG_ENDIAN /* The host byte order is the same as network byte order, so these functions are all just identity. */ # define ntohl(x) (x) # define ntohs(x) (x) # define htonl(x) (x) # define htons(x) (x) # else # if __BYTE_ORDER == __LITTLE_ENDIAN # define ntohl(x) __bswap_32 (x) # define ntohs(x) __bswap_16 (x) # define htonl(x) __bswap_32 (x) # define htons(x) __bswap_16 (x) # endif # endif #endifMůj zkušební kód po
gcc -E -O (Debian 4.3.3-7) dopadne takto:
int main() {
unsigned short int w1, w2;
w1 = 0x1234;
w2 = (__extension__ ({
register unsigned short int __v, __x = (w1);
if (__builtin_constant_p (__x))
__v = ((((__x) >> 8) & 0xff) | (((__x) & 0xff) << 8));
else
__asm__ ("rorw $8, %w0" : "=r" (__v) : "0" (__x) : "cc");
__v;
}));
printf("%x\n", w2);
return 0;
}
Přiřazení s w2 = … bylo původně w2 = ntohs(w1), při zapnutých optimalizacích
tedy w2 = __bswap_16(w1). Rozvoj makra je v příspěvku vidět.
Bitové operace v první větvi podmínky vyvolají onu hlášku. Kód se navíc vykoná jen tehdy, pokud je hodnota známá
během překladu, pro proměnnou se použije vložený kus asembleru.
Kód se navíc vykoná jen tehdy, pokud je hodnota známá během překladu, pro proměnnou se použije vložený kus asembleru.
V podstatě máte pravdu, ale formulace "kód se vykoná" není přesná. To větvení je tam právě proto, že je-li argument konstanta, (neefektivní) výpočet podle vozorečku provede samotný překladač a do kódu jde rovnou výsledná konstanta (stejně jako když napíšete třeba int a = 1 + 1).
Tiskni
Sdílej: