Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »int main(void) { int a = 0, b = 0, soucet = 0, polea[11]; char c, poleb[11]; FILE *fr; int d; if((fr = fopen("ctvrtek.txt","r")) == NULL) { printf("Soubor se nepodarilo otevrit!!\n"); return 1; } while((c = getc(fr)) != EOF) { if(c >= '0' && c <= '9') { poleb[a] = c; a = a + 1; } else { if(poleb[0] != '\0' && a != 0) { //plati pokud je v poli znak a a nesmi byt 0 polea[b] = atoi(poleb); for(d = 0; d <= 11; d++) { poleb[d] = '\0'; } a = 0; b = b + 1; } } } if(poleb[0] != '\0') { polea[b] = atoi(poleb); } if(fclose(fr) == EOF) { printf("Soubor se nepodarilo zavrit!!\n"); return 1; } for(d = 0; d < b; d++) { printf("%d. vysledne cislo: %d\n", d+1, polea[d]); soucet = soucet + polea[d]; } printf("Soucet: %d", soucet); return EXIT_SUCCESS; }
Tady konkrétně nerozumím proč v tom programu má být
for(d = 0; d <= 11; d++) { poleb[d] = '\0'; }
Proč ten nulový znak(ukončení řetezce) má být za každým znakem? ukončuje se celý řetězec ne? proč 11x?
a potomif(poleb[0] != '\0') { polea[b] = atoi(poleb); }
První problém je chybějící kontext, takže budu předpokládat, že jste dostal cizí program a snažíte se přijít na to, co dělá. Odpověď je, že přečte vstupní soubor, vytahá z něj souvislé posloupnosti číslic, převede je na čísla, ta čísla vypíše a sečte.
Co se týká těch dvou fragmentů, tak první prostě vyplní poleb
nulovými znaky, než do něj začne načítat další posloupnost číslic. Tenhle krok byste si samozřejmě mohl odpustit, pokud byste před převodem (tj. při první nečíslici nebo na konci souboru, pokud končil číslicí) ten nulový znak na konec připsal.
Druhý fragment převede poslední posloupnost číslic v případě, že za ní nebyl jiný znak, ale sahala až do konce souboru. Tady je ale chyba, protože autor zapomněl inkrementovat b
, takže to poslední číslo se v takovém případě nevypíše a nezapočítá do součtu.
Těch chyb je tam víc, např. chybí kontrola, že posloupnost číslic nemá víc než 10 znaků (má-li 11, předáte atoi()
neukončený řetězec, má-li víc, přeteče vám to už při zápisu do poleb
). Stejně tak chybí kontrola, že těch čísel tam není víc než 11 (jinak přeteče polea
). A pokud soubor bude začínat něčím jiným než číslicí, máte tam čtení z neinicializovaného poleb[0]
. V kontrastu s tím působí úsměvně snaha pečlivě ošetřit a nahlásit selhání fclose()
, což je vysoce nepravděpodobný scénář, stejně s tím nic nenaděláte, stejně se soubor nakonec zavře při ukončení programu a protože byl otevřený pro čtení, nebude to ani ničemu vadit.
Další problém je
while((c = getc(fr)) != EOF)
kde c
je char
a ne int
. Při troše štěstí to možná fungovat bude, ale i pak to bude hodně záviset na konkrétní verzi překladače a libc (a nejspíš i architektuře).
Jestli mluvíte o tom chybějícím b++
tak problém není v tom, že by se číslice nepřevedly a neuložily, ale v tom, že neaktualizujete proměnnou b
, kde máte počet prvků polea
(mimochodem, a
pro počet prvků poleb
a b
pro počet prvků polea
je opravdu vynalézavé), takže následující smyčka to poslední číslo nezpracuje.
Samozřejmě to ale nastane jen v případě, že máte číslice opravdu až na konci souboru, ne pokud za nimi bude ještě např. newline ('\n'
).
Nejjednodušší je prostě navíc inkrementovat b
, např.
if (poleb[0] == '\0') { polea[b] = atoi(poleb); b++; }
což bych asi spíš přepsal
if (!poleb[0]) polea[b++] = atoi(poleb);
ale to už by asi bylo lepší to celé přepsat úplně od základu. Např. ani jedno z těch polí ve skutečnosti není potřeba (tím odpadnou i problémy s nehlídaným přetečením), open coding věci jako isdigit()
nebo memset()
vede jen k horší čitelnosti a zvyšuje riziko chyb atd. Podle těch podivných jmen proměnných to ale skoro vypadá, jako by nečitelnost byla cílem.
Při troše štěstí to možná fungovat bude, ale i pak to bude hodně záviset na konkrétní verzi překladače a libc (a nejspíš i architektuře).
Celkem bez závislosti na libc a překladači a architektuře to prostě selže, pokud v souboru bude byte 0xff. (Pravda, teoreticky by mohlo být EOF != -1
, ale to by bylo hodně překvapivé. Navíc by to chybu neodstranilo, protože by se ten EOF
prostě „převedl“ (poněkud ztrátově) zase na jiný specifický char
, který by se pak mylně pokládal za konec souboru.)
Zkrátka, tohle bude mylně považovat byte s hodnotou 0xff (255, bráno bez znaménka, nebo -1, bráno se znaménkem) za konec souboru, protože obvykle EOF == -1
a char
je znaménkový.
Že getc()
vrací int
, nikoliv char
, k tomu je přesně tenhle důvod.
char c: byte 0xff bude -1 (== EOF)
int c: byte 0xff bude 255 (!= EOF)
Tady je řeč o něčem jiném: o testu konce souboru. Funkce getchar()
vrací int
(a ne char
) právě proto, aby bylo možné mít speciální hodnotu pro EOF, která se liší od toho, co getchar()
vrátí pro kterýkoli skutečný znak (nebo spíš byte).
Pokud ještě před testem na EOF návratovou hodnotu převedete na char
, EOF se nutně převede na stejnou hodnotu jako některý skutečný byte, který se v souboru může vyskytnout. V závislosti na tom, jak napíšete to porovnání, a na implementaci getchar()
, char
a EOF
pak buď budete mít byte, který (pokud se v souboru vyskytne) vyhodnotíte jako konec, nebo nepoznáte ten skutečný EOF.
protože obvykle EOF == -1 a char je znaménkový
Tohle je právě to uvažování, kterému je lepší se vyhnout. Na jedné straně sice opravdu obskurních prostředí ubývá, ale na druhé mají moderní překladače tendenci využívat k agresivním optimalizacím i toho, že něco je ve specifikaci uvedeno jako undefined behavior. Někde jsem narazil na příklad, že smyčku
int i; for (i = 1; i; i++) { ... }
může takový překladač úplně vyhodit, protože chování při přetečení je u unsigned typů undefined behavior. A může to udělat i překladač, který jinak int
a operace s ním implementuje tím obvyklým způsobem, při kterém se to na tu nulu nakonec dostane. (Aktuální gcc to nedělá, aspoň ne defaultně, ale při zapnuté optimalizaci už vyhodí warning.)
Osobně char
používám jen tam, kde prvky opravdu chci chápat jako znaky; pokud s nimi chci pracovat jako s čísly, pak raději uint8_t
a int8_t
(resp. u8
a s8
).
protože obvykle EOF == -1 a char je znaménkovýTohle je právě to uvažování, kterému je lepší se vyhnout.
Není vůbec nic špatného na úvaze, co například může být EOF
a co může vzniknout jeho konverzí na char
. Špatné by bylo počítat automaticky s tím, že EOF
je -1, což ale nikde neradím. Naopak říkám, že bez ohledu na definici EOF
to nebude nikdy správně fungovat. Kterýkoliv byte vzniklý konverzí EOF
na char
(ať už to bude 0xff nebo jiný) bude chybně považovaný za konec souboru.
proč jako používat čísílka když už jako máme definovaný tamto makro eof :O :D
joa taky je tam jako někde taková ta funkcička feof ;D
proč jako používat čísílka když už jako máme definovaný tamto makro eof :O :D
Nikdo v celém tomto vlákně nenavrhoval, ba ani nenaznačoval, že by se někde měla "používat" nějaká čísla. Pak je otázka, na co vlastně reaguješ.
joa taky je tam jako někde taková ta funkcička feof ;D
Což může být fajn, když čtu víc souborů najednou a chci se později podívat, které už jsem dočetl. (Třeba příkaz paste
by něco takového mohl s výhodou použít.) Nicméně pro jeden soubor čtený v jednom cyklu [tento případ] je overkill volat po každém znaku feof()
. Stačí brát z fgetc()
správný návratový typ (int
) a EOF
se pak nebude rovnat žádnému jednomu bytu.
sorry sem to jenom přelítla vočima a vidim eof==-1 :O :O ;D
co se jako týká tý feof tak jsem jako myslela že se jako řeší nějakej paranoidní scénář kdy se nějak nedá jakoby 100% spolehnout jenom na eof a nato se fukncička feof hodí protože vona nekouká na znak eof vona kouká o malililinkaťoučkej kousíček dál hele :O :O :O :O ;D
The function feof() is used to check the end of file after EOF. It tests the end of file indicator. It returns non-zero value if successful otherwise, zero.
ale jako žeto je pro dooyerův domácák overkill toje jako jasný ;D
chování při přetečení je u unsigned typů undefined behaviorSigned, ne? U unsigned to legálně přeteče na nulu.
todleto tam je jako uplně nahouby však ;D
taky tam jako neni vošetřený přetečení proměný když ty čísla budou moc velký ;D
1. vysledne cislo: 1234567680 2. vysledne cislo: 1234585655 3. vysledne cislo: 371679162 4. vysledne cislo: 1360599260 5. vysledne cislo: 454554 6. vysledne cislo: 555 7. vysledne cislo: 4545445 Soucet: -88534985ale teď už jako fakt musim běžet :O :'(
mý řešení dooyerova domácáku :D :D
#include <stdio.h> #include <stdlib.h> #include <errno.h> #include <limits.h> int main ( void ) { //soubor FILE * fr=NULL; //přečtenej řádek ze souboru char * radek = NULL; //velikost bufferu kterej si alokuje getline pro čtení řádku size_t velikostBufferu = 0; //kolik jako sme přečetli znaků :O //to ssize je jakoby signed size_t takže muže bejt záporná :O :O ssize_t read; //sem si to jako budeme sčítat všecko long suma=0; if ( ( fr = fopen ( "input.txt","r" ) ) == NULL ) { fprintf ( stderr,"Soubor se nepodarilo otevrit!!\n" ); exit ( EXIT_FAILURE ); } //budem číst soubor řádek po řádečku ;D //getline přečte řádek do proměný radek //pokud to nepude vrátí -1 //třeba když jako máme to EOF //víc o getline tady https://linux.die.net/man/3/getline while ( ( read = getline ( &radek, &velikostBufferu, fr ) ) != -1 ) { printf ( "zpracovava se retezec: %s",radek ); //tady jako dost dobře mužem předpokládat nějakou hezkou chybku //proměná errno z errno.h drží číslo poslední chyby //vynulujem jestli tam už něco bylo předem //nulička znamená jako dobrý žádná chyba ;D errno=0; //teďko si to převedem funkcí strtol na číslo ;D //https://linux.die.net/man/3/strtol //první argument je řetězec znaků //druhej je takovej endptr ten drží první nečíselnej znak na kterej funkce narazí. pokud obsahuje vstupní string tak sme jako nenašli žádný čísla!!!! :O :O //posledním argumentem nastavujem aby to jako počítalo s číslem v desítkový soustavě ;D char * endptr; long hodnota = strtol ( radek, &endptr, 10 ); //kouknem do proměný errno jestli se nám to jako povedlo //kódový číslo ERANGE řiká že hodnota je jako mimo povolenej rosach if ( ( errno == ERANGE && ( hodnota == LONG_MAX || hodnota == LONG_MIN ) ) ) { //perror ( "strtol" ); //profík by použil perror ;D //hele https://linux.die.net/man/3/perror fprintf ( stderr, "out of range chyba!!!!\n" ); exit ( EXIT_FAILURE ); } //tady budem chytat tak nějak obecně :D else if ( errno != 0 && hodnota == 0 ) { fprintf ( stderr, "chyba!!!!\n" ); exit ( EXIT_FAILURE ); } if ( endptr == radek ) { fprintf ( stderr, "zadny nalezeny cisla v stringu jako!!\n" ); exit ( EXIT_FAILURE ); } //a teď si jako přičtem hodnotu k sumě s tim že budem aspoň trošku hlídat overflow long origSuma=suma; suma+=hodnota; if ((hodnota>0 && origSuma>0 && suma<0)||(hodnota<0 && origSuma<0 && suma>0)) { fprintf ( stderr, "preteceni promeny suma jako!!\n" ); exit ( EXIT_FAILURE ); } //všecko vypišeme printf ( "hodnota: %ld\nvelikost bufferu: %zd\n(int)endptr: %d\nsuma: %ld\n\n",hodnota,velikostBufferu, ( int ) ( *endptr ),suma ); } if ( radek ) { free ( radek ); //uklídíme po sobě paměť řádku } if ( fclose ( fr ) != 0 ) { fprintf ( stderr,"Soubor se nepodarilo zavrit!!\n" ); exit ( EXIT_FAILURE ); } printf ( "hotovo!!!!!!!!!!!!!!!!!!!!!!!!!!!\n" ); return EXIT_SUCCESS; }
a jako s pravdou ven že se potobě chce sčítat ty dlouhatatánský člísla ve stringzích pod sebe?? ;D
třeba jako sem zalezlá pod postelí a strašně se snažim nesesmolit hnus :O :O :D :D
sem si tu miriam jenom pučila na dělání bordýlku jinak jako vo ni vim asi tolik co ty vo mě :O ;D
na disku mam zatim ještě všecko tak nevim :D :D
ale jako máš pravdu stim undefined behavior lepší je tomu overflow jakoby předejít než koukat jestli se jako stalo tááákže
#include <stdio.h> #include <stdlib.h> #include <limits.h> int add ( long * k_cemu,const long a_co_jako ) { if ( ( *k_cemu>0 && a_co_jako>LONG_MAX-*k_cemu ) || ( *k_cemu<0 && a_co_jako<LONG_MIN-*k_cemu ) ) { fprintf ( stderr,"pozor!!!!!!!!\nscitat %ld a %ld nebudu jako!!!!\nbylo by overflow/underflow!!!!!!!!\n",*k_cemu,a_c> return EXIT_FAILURE; } else { *k_cemu+=a_co_jako; } return EXIT_SUCCESS; } int main ( void ) { const long skoroMAX=LONG_MAX-1; const long minusSkoroMAX=LONG_MIN+1; long sum=0; while ( add ( &sum,skoroMAX ) !=EXIT_FAILURE ) { printf ( "sum: %ld\n" ); } sum=0; while ( add ( &sum,minusSkoroMAX ) !=EXIT_FAILURE ) { printf ( "sum: %ld\n" ); } return 0; }
jo a je takový zajímavý že u unsigned se to muže dělat něco takovýho u unsigned ub neni :O :O :O :O
Tiskni
Sdílej: