Společnost Eclypsium se na svém blogu rozepsala o bezpečnostním problému počítačů Framework. Jedná se o zranitelnost v UEFI umožňující útočníkům obejít Secure Boot.
Editor kódů Zed (Wikipedie) po macOS a Linuxu s verzí 0.208.4 už běží také ve Windows.
Apple dnes představil 14palcový MacBook Pro, iPad Pro a Apple Vision Pro s novým čipem M5.
Debian pro mobilní zařízení Mobian (Wikipedie) byl vydán ve verzi 13 Trixie. Nová stabilní verze je k dispozici pro PINE64 PinePhone, PinePhone Pro a PineTab, Purism Librem 5, Google Pixel 3a a 3a XL, OnePlus 6 a 6T a Xiaomi Pocophone F1.
Operátor O2 představil tarif Datamanie 1200 GB . Nový tarif přináší 1200 GB dat s neomezenou 5G rychlostí, a také možnost neomezeného volání do všech sítí za 15 Kč na den. Při roční variantě předplatného zákazníci získají po provedení jednorázové platby celou porci dat najednou a mohou je bezstarostně čerpat kdykoli během roku. Do 13. listopadu jej O2 nabízí za zvýhodněných 2 988 Kč. Při průměrné spotřebě tak 100 GB dat vychází na 249 Kč měsíčně.
Byly publikovány informace o útoku na zařízení s Androidem pojmenovaném Pixnapping Attack (CVE-2025-48561). Aplikace může číst citlivá data zobrazovaná jinou aplikací. V demonstračním videu aplikace čte 2FA kódy z Google Authenticatoru.
Free Software Foundation (FSF) spustila projekt Librephone, jehož cílem je vytvoření svobodného operačního systému pro mobilní telefony. Bez binárních blobů.
Byla vydána verze 7 s kódovým název Gigi linuxové distribuce LMDE (Linux Mint Debian Edition). Podrobnosti v poznámkách k vydání. Linux Mint vychází z Ubuntu. LMDE je postaveno na Debianu.
Byl vydán Mozilla Firefox 144.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vypíchnout lze lepší správu profilů. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 144 bude brzy k dispozici také na Flathubu a Snapcraftu.
Discord potvrdil únik osobních údajů přibližně 70 000 uživatelů. Incident se týká uživatelů po celém světě, především těch, kteří v rámci ověřování svého věku nahráli do aplikace doklad totožnosti. Únik informací se netýkal systémů samotné platformy, ale došlo k němu přes kompromitovaný účet pracovníka zákaznické podpory u externího poskytovatele služeb.
Autor tohoto blogu, Mgr. Šimon Tóth v současné době působí jako výzkumný pracovník ve společnosti Cesnet z.s.p.o. a dlouhodobě vede pokročilá a speciální cvičení jazyků C a C++ na Fakultě informatiky MU.
linkedinBlíží se nám nový standard C++, který by měl přinést spoustu novinek a také odstranit některé otravné nepříjemnosti. Jednou z novinek je zavedení jednotné syntaxe pro inicializátory. Tohle mně inspirovalo k zamyšlení zda by nešlo v současném C++ udělat docela často potřebovanou věc, incializace dynamických polí hodnotou.
Když vytvoříte v C++ dynamické pole, musíte ho pak inicializovat prvek po prvku. Tudíž aktuální kód by mohl vypadat nějak takhle.
int * pole = new int[10]; for (int i = 0; i < 10; i++) { pole[i] = i; }
I když tento kód vypadá naprosto v pořádku má jednu fatální vadu. Pokud budeme inicializovat pole objektů, musí mít daná třída defaultní konstruktor. To ale může být větším problémem než se může na první pohled zdát. Každý objekt totiž má svůj interní stav a kvůli možnosti vytvářet pole objektů musíme přidat stav vytvořen-ale-neinicializován, což může být (hlavně pokud jde o externí kód) nepřekonatelný problém.
S myšlenkou že v C++ jde naprogramovat všechno, jsem si sedl ke Googlu a hledal. Naštěstí jsem už dopředu věděl co vlastně hledám, jelikož jsem na potřebný kód narazil už dříve (v jiném kontextu). I přesto mi hledání (pravděpodobně díky mé nekonečné blbosti) trvalo několik hodin, nicméně výsledek stál za to.
Základem celé myšlenky je málo známá varianta operátoru new
. Operátor new
totiž umožňuje totiž specifikovat paměťové místo kde má daný objekt inicializovat. Opravená verze výše uvedeného kódu, bude pak vypadat nějak takhle.
NaseTrida * pole = malloc(sizeof(NaseTrida)*10); for (int i = 0; i < 10; i++) { new(&pole[i]) NaseTrida(i); }
Pozor si pak musíme dávat při uvolňování alokovaných objektů. Musíme jim explicitně zavolat destruktor a pak uvolnit paměťový blok pomocí free
.
Protože základní programátorskou poučkou programátora C++ je psát malé jednoúčelové zapouzdřené kusy kódu, tady je relativně primitivní objektový obal pro výše uvedený kód. Třída používá moje vlastní asserce, které jsou trochu více popisné než ty standardní. Rozhodně nezaručuji ze je třída na 100% funkční, nicméně zatím jsem nenarazil na žádný problém.
Obal poskytuje dvě metody pro předávání parametrů. Jedna předává všem třídám stejnou hodnotu, druhá je inicializace polem hodnot.
EDIT 12.9. 11:05 Kód přesunut do samostatného obarveného souboru: VariableArray.html
Tiskni
Sdílej:
*** glibc detected *** ./a.out: free(): invalid pointer: 0x000000000040061c ***
'a=b'
jindy zase 'a != b'
)
moveable instance
struct Point { int x, y; }Některé třídy (struktury) jsou přímo stvořeny k tomu, aby se přesouvaly s místa na místo, tak tady netvrďte bláboly. Dokonce i třída s virtualní tabulkou funkcí se takto muže přesouvat.
char* buffer = new char[10];
?
A kdyby docházelo ke zbytečné inicializaci, pak by program běžel pomaleji následkem neužitečné inicializace,vs.
i v jiných programátorských jazycích, kde se automaticky inicializuje patří k dobrému vychování a k dobrým programátorským technikám toto nevyužívat, ale explicitně to nastavit ve zdrojovém kódu.hlavne, ze mate jasno....
patří k dobrému vychování a k dobrým programátorským technikám toto nevyužívatjsou jazyky, kde se na efektivitu moc nehledi... tak to udelame jeste neefektivnejsi ;-]
A proč by to dělal? Kdyby C++ automaticky inicializoval (zejména POD typy), tak by dělal naprosto zbytečnou práci, protože programátor to potřebuje nastavit po svém a kompilátor nemá naprosto šanci odhadnout jak.Ad 1) Aby se předešlo celé třídě nedeterministických a proto obtížně odhalitelných programátorských chyb. Aby se dala vytvořit rozumná knihovna pro garbage collection, která nebude muset bojovat s tím že pointery v objektech nemusejí být vždy validní. Aby člověk nemusel psát tolik triviálního kódu do konstruktoru. Ad 2) Proč by ta 6MB tlustá hromada sraček nemohla využívat statickou analýzu kódu, kterou beztak dělá. Konstruktor by na začátku vynulovat ty části objektu, pro které nejde garantovat že jsou inicializovány. Pokud programátor bezpodmínečně inicializuje vše, nemusí se nulovat nic.
template<class T> struct Wde_StaticClass { uint8_t _storage[sizeof(T)]; inline void init() { new ((void*)_storage) T; } inline void destroy() { ((T*)(_storage))->~T(); } inline T& instance() { return *((T*)(void*)(_storage)); } inline const T& instance() const { return *((T*)(void*)(_storage)); } };Je to sice trosku brutal pretypovavani, ale plni to ucel pri staticke inicializaci instanci (to byla motivace). Kdyz se pretypuje operator -> tak se s tim muze pracovat jako s ukazatelem.
std::vector
, který taky defaultní konstruktor nepotřebuje?
Při použití STL není prakticky možné dělat sdílené knihovny
Mohl byste tuto myšlenku rozvést?
#include "variablearray.h" struct except { static int counter; except(int i = 0) { ++counter; if( ! (counter % 3) ) throw "Vyjimka!"; } }; int except::counter = 0; int main(int argc, char** argv) { try { VariableArray<except%gt; va; va.Init(10); } catch(...) { } try { VariableArray<except> va; va.Init(10, 1); } catch(...) { } VariableArray<int> va; va.Init(10); va = va; return 0; }
except
y)
assert(_length!=0,"Trying to free uninitialized pointer"); if (_length != 0) {}
int main(int argc, char** argv) { // 1) instance se naalokují pomocí placement new, ale vyjimka zpusobi // ze se neuvolni (viz implementace a destruktor), takze pokud byly // uvnitr alokovany dynamicke data -> leak try { VariableArray<except> va; va.Init(10); } catch(...) { } // 2) to same jako 1 try { VariableArray<except> va; va.Init(10, 1); } catch(...) { } // 3) VariableArray<int> va; va.Init(10); // nedefinovane chovani, kopiruji se a alokuji vlastni // data do vlastni třídy (viz kopirovaci konstruktor, tento // pripad neni osetren) -- toto bude asi dalsi leak nebo // primo segfault, zalezi na typu 'Type' va = va; return 0; }
int main(int argc, char** argv) { // 1) instance se naalokují pomocí obyčejného new[], který při výjimce // sám zavolá destruktory dosud zkonstruovaných objektů // Naštěstí je pole označeno jako prázdné, takže destruktor va nic nemůže pokazit try { VariableArray<except> va; va.Init(10); } catch(...) { } // 2) tady se používá placement new, takže objekty except nikdo neuvolní. Navíc, // je pole označno jako plné, inicializované pomocí new[] try { VariableArray<except> va; va.Init(10, 1); } catch(...) { } // Destruktor va uvolnil paměť alokovanou mallocem pomocí delete[]. To je // nedef. chování // 3) VariableArray<int> va; va.Init(10); // tento případ není ošetřen, ale nejde o nedef. chování. Když se podíváte do kódu // operátoru=, zjistíte, že se chytne hned ta podmínka if(_length) Free(). Tím // se smažou nejen vlastní data, ale i data rhs a další kód s tím nic neudělá // nezáleží to vůbec na ničem va = va;
Je krásné, jak tady všichni polemizují, ale co takle nějaké srovnání?
Rychlost, uvolňování paměti atd? Já zkoušel porovnat následující:
1) vytvoření pole ukazatelů velikost 10000 na char velikosti 10000B
2) následně dealokace všech charů velikosti 10000B přes delete
3) alokace charů 1B na již existujících 10000 ukazatelů
4) alokace dalších 10000000 ukazatelů na char velikosti 1B
5) vyhodnoceni
Měření jsem provedl pro následující dvě varianty:
* to co navrhuje autor: pro seznam ukazatelů (malloc, realloc), pak (new, delete, new)...
* místo malloc použit vector: pro seznam ukazatelů (vector, push_back), pak (new, delete, new)...
Závěr: malloc lépe pracuje s pamětí - po delete ji sice systém neuvolní a program stále zabírá asi 100 MB v RAM, ale následně je plně využita pro další alokaci (po doběhnutí programu zabráno asi 191MB RAM)... vector má v mém měření skoro 2x vetší režii na paměť - po delete systém taky neuvolní paměť, ale při následné alokaci zabírá další a další RAM (nevyužije tu co byla uvolněna přes delete) a po doběhnutí program skončí na 350 MB RAM.
Příklad pro realokaci je zde:
http://www.krokodyyl.wz.cz/programovani/prog14.php
Pro mé konkrétní řešení se jednoznačně hodí metoda, kterou popisuje autor článku, případně je to ještě lépe popsáno v odkazu, který jsem uvedl... Ať si každý používá to, co mu vyhovuje, ne? Někdo extrémně optimalizuje rychlost a paměť (a musí si víc hlídat kód), někdo nepotřebuje optimalizovat, tak píše elegantní kód... Za mě velké díky za článek!
Radek