Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
#include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/types.h> #include <sys/wait.h> #include <string.h> #include <unistd.h> static char **enviroment; void command_info() { pid_t pid; int status; char *parameters[]={"uname", "-a", NULL}; pid=fork(); if(pid == 0) { execve("/bin/uname", parameters, enviroment); perror("execve"); } else wait(&status); } int loop() { char buffer[1000]; memset(buffer, 0, 1000); fgets(buffer, 1000, stdin); if(strncmp(buffer, "help", 4) == 0) { puts("Commands: help info exit"); return 0; } if(strncmp(buffer, "info", 4) == 0) { command_info(); return 0; } if(strncmp(buffer, "exit", 4) == 0) { return 1; } return 0; } int main(int argc, char **argv, char **env) { enviroment=env; while(1) if(loop()==1) break; return 0; }
Tiskni
Sdílej:
Memset s bufferem? To je potencialni dira a memleak.
Mohl byste tuhle myšlenku nějak objasnit? Samozřejmě by čistší bylo
memset(buffer, 0, sizeof(buffer));
nebo raději rovnou
char buff[BUFF_LEN] = {};
nebo
char buff[BUFF_LEN] = "";
ale jak z inicializace lokální proměnné uděláte memleak, to bych si docela rád poslechl.
Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.
mít takhle velkou proměnnou na stacku.napr. u funkce, ktera pise do logu a jako parametr dostane vetsi text se s ti neco udelat musi. Co pouzivate potom. Static, malloc, extern ? Ja pouzivam static uvnitr funkce a priznam se, ze jsem vlastne nikdy nezkousel, kde se to uklada
malloc()
apod. V jádře je vzhledem k velikosti stacku tlak na šetření hodně velký, ale ani v userspace není dobré si představovat, že je stack nekonečný. Resource limit na velikost stacku (ulimit -s
) sice bývá něco jako 8 MB, ale to je pro všechny thready dohromady, takže u multithreadových programů běžně používám stack o velikosti 64 KB nebo dokonce 16 KB - a pak už si rozmyslíte, jestli tak velkou část zaplácnout nějakým bufferem.
my dodavame programy do firmy, ktera se nachazi v obci Rust a kolega kdysi delal nekolik excelovych zpracovani pro mestsky urad v obci Perl. Je zajimave, ze pro radu programu existuje obec, ktera se zrovna tak jmenuje+ ještě Kotlin a Java. Lua, Saint-Python, Cobol, Fortran, Scala, C++, Ruby, …
move
s Vámi soublasím – to by měl řešit spíš kompilátor. Na druhou stranu, proti let mut
/mut
nic nemám (pořád hezčí než const
v C++) – alespoň si v tom musím udělat jasno předem. (Kotlin má val
(jako let
) a var
(jako let mut
) a tam mě to spíš obtěžuje, zčásti protože si tato klíčová slova jsou tak podobná, že se snadno spletou.)
Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.
Mě teda spíš vadí to, že má takhle velkej buffer, když do něj čte maximálně 4 byty... Víc commandů za sebou to neumí, zbytek načteného bufferu stejně zahazuje. Kdyby tam měl odpovídající - 4 bytovej buffer - tak si ho dovedu na stacku klidně představit i v kernelu . Celkově bych to nazval jako "céčko od ne-céčkaře" (vyloženě z toho čiší neznalost základních principů, jako co je v C string a jak je reprezentovaný, co je stream a jak funguje standardní vstup, ...). Nějak takhle asi vypadaj moje programy v pythonu
.
Podle me 1000 bytu je mala promena, pokud se bavime o platforme, kde nejmensi velikost pridelene pameti na stack je jedna stranka (takze da se rict kazda platforma s MMU). Pokud uz je stack naalokovany, je to nejefektivnejsi metoda, jak ziskat docasnou pamet - jen se navysi stack pointer (proto ma alloca obcas svuj smysl, treba kod llvm je toho plny).Asi je to profesionální deformace, ale spíš mi vadí ten samotný nápad mít takhle velkou proměnnou na stacku.
Podle me 1000 bytu je mala promena, pokud se bavime o platforme, kde nejmensi velikost pridelene pameti na stack je jedna stranka (takze da se rict kazda platforma s MMU).
A taková proměnná vám zabere čtvrtinu té stránky, to je docela dost, aby se nad tím vývojář aspoň řádně zamyslel. Nemluvě o tom, že v civilizovaném programu těch 1000 nebude natvrdo zadrátovaná konstanta, čímž se problém posouvá na novou úroveň. (Viz např. čistka VLA v jádře pár let zpátky.)
proto ma alloca obcas svuj smysl, treba kod llvm je toho plny
Snad jsou aspoň trochu prozíravější než autor resolveru v glibc, který také miluje alloca()
, ale bohužel má malou představivost ohledně toho, jak velká může být odpověď nebo kolik IPv6 adres může host používat, takže ten zásobník tu a tam přeteče…
Co s tim jako?Reakce na tohle: https://www.abclinuxu.cz/poradna/linux/show/473630
jaktože to jakoby má jenom 23 zobrazení ale už 12 hlasů :D
ok tudlectu výmluvu žeru ;D ;D
while(1) if(loop()==1) break;Stačí naspat:
while(loop() != 1)nebo
== 0
, ale to může mít jiný význam v závislosti na tom, jaké hodnoty vracíš.
while(!loop());
… radeji vidim true/false a EXIT_* nez return 0/1, while(1), atd.Souhlasím. Mám také raději „ukecanější” kód ze kterého je jasné co se kdy děje, než rébusy, u kterých lze návratovou hodnotu snadno zaměnit. Číselné hodnoty využívám jako návratovou hodnotu jen tam, kde potřebuji odchytnout konkrétní místo.