Příspěvky

1

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 18. 03. 2026, 11:06:06 »

Váš kousek kódu může mít nedefinované chování kvůli aliasingu.

A to prosím kde/jak?

2

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 16. 03. 2026, 14:26:25 »

Tu podmíněnou kompilaci ale nedělá jazyk C ale C preprocesor.
Je to separátní tool, který ani nerozumí kompletní syntaxi C a používá se i pro jiné jazyky. Integrace preprocesoru do překladače proběhla až relativně nedávno, protože to oddělení mělo nepříjemné důsledky na použitelnost.

Tak jakto že The C Programming Language od Kernighana a Ritchieho z roku 1978 zmiňuje preprocesor?

Abych dostal to makro ENDIANESS tak musím mít někde mrtě platformně závislé logiky.

To je prosím celá mrtě logika, která je potřeba pro detekci endianity buildtoolem - ten checkne návratový kód.

Kód: [Vybrat]

#include <stdint.h>

int main(void)
{
    uint32_t x = 1;
    uint8_t *p = (uint8_t  *)&x;

    return p[0] == 1;
}
Ano na nějakých exotických systémech to asi i tak selže, ale umí toto nějaký jazyk lépe? V praxi na jakémkoliv moderním systému to bude fungovat.

Další věc je, že endianita se dá kompletně odstínit pomocí OR a posuvů, takový kód je pak na endianitě nezávislý.

Btw, drtivá většina C kódu není přenositelná, ale je psaná v nějakém platformně závislém dialektu. Je to proto, že v přenositelné podmnožině C chybí naprosto zásadní věci. Např linux není psaný v C ale v GCC dialektu a při portování do clangu se do něj ten GCC dialekt přidal.

Linux je nejpřenositelnější OS jaký existuje No a nemyslím si že používají GCC kvůli tomu že by C nebylo přenositelné. Inline assembler je spíše praktická věc pro OS kód. Různé builtin funkce jsou spíše optimalizační techniky. Makro typeof zase umožňuje generičtější kód, což jenom šetří psaní... dalo by se bez toho všeho obejít. Které věci z GCC dialektu jsou striktně kvůli přenositelnosti bez kterých by se nedalo obejít?

3

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 12. 03. 2026, 15:20:49 »

Na to stačí jednoduchý #ifdef
případně runtime detekce se dá udělat taky, jak pro endianitu, tak pro dvojkový doplněk.

K ostatnímu se nebudu vracet, ale ten jednoduchý ifdef třeba na endiany bych chtěl vidět. Normálně potkávám několik obrazovek ifdefů, protože každý překladač, platforma a občas i verze mají ty makra nějak jinak.

A jak souvisí překladač, platforma, verze a nebo název makra s tím jestli je jazyk přenositelný? Toto makro má nakonfigurovat build systém a předat ho překladači.

V režii jazyka už pak je jenom podmíňěná kompilace na tu nebo onu variantu.

Jestli je něco v jednom nebo deseti vnořených #ifdefech není z pohledu přenositelnosti důležité.

Jednoduchý ifndef:

#ifndef ENDIANESS
#error "ENDIANESS not set"
#endif

to je, co?

#if ENDIANESS == BIG_ENDIAN
...
#else
...
#endif

4

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 12. 03. 2026, 12:26:18 »

Pokud použiju separátní tool (který ani nezná kompletní syntaxi C) abych jím lepil platformně závislé kousky textu dohromady, můžu ještě mluvit o přenositelném jazyce?

V C lze psát jak přenositelně, tak nepřenostitelně. Které věci jsou přenositelné, a které ne, je nutné znát.

A věci jako endiany nebo jestli mám vůbec dvojkový doplněk se zjišťují hůř.

Na to stačí jednoduchý #ifdef
případně runtime detekce se dá udělat taky, jak pro endianitu, tak pro dvojkový doplněk.

Tak zrovna u charu je to "implementation defined". Takže jazyk C definuje jen to, že to kompilátor "overridnout" prostě musí.

u charu ano. U unsigned charu a signed charu nikoliv, ty jsou jasně definované. Jazyk je nabízí... takže co, zase tu budu řešit že někdo chtěl unsigned char a to unsigned tam nenapsal (a naopak)? Tady žádný problém v přenositelnosti z pohledu jazyka není.

Ano, v C se dá psát přenositelný kód. Ale protože je to jazyk z punkových časů, tak toho ta přenositelná podmnožina až tak moc neumí. A málo šedivé programátory to může překvapit, protože spousta těch věcí z dnešního pohledu už fakt nedává smysl.

Super, takže se shodneme - C je přenositelný jazyk. Tímto můžeme debatu uzavřít.

5

Vývoj / Re:Rozdíl mezi ASM a strojovým kódem

« kdy: 09. 03. 2026, 10:32:56 »

Teprve jazyk C vyřešil přenositelnost.

V rámci možností. Pokud člověk například nepotřebuje vědět, jestli char je signed nebo unsigned. Nebo jak velký je int. Viz nedávné flame vlákno o bit shiftování signed intu.

To jsou zase plky
Pokud někdo potřebuje zajistit přesnou velikost typu přenositelným způsobem, tak na to je knihovna <stdint.h>, která je součást standardu. Jestli je něco signed nebo unsigned jazyk definuje taky - že to pak nějaký kompilátor overridne je druhá věc. A bit shift signed intu je prostě UB, tak shiftuj unsigned a taky máš přenositelný program.

6

Studium a uplatnění / Re:Jak se naučit základy programování na VŠ?

« kdy: 20. 02. 2026, 13:45:00 »

Kód: [Vybrat]

pokud voda bubla ... nalej ji do hrnku
pokud ne, bez o krok zpet


Je vidět, že ses tu algoritmizaci neučil déle než těch tvých deset minut.
Pokud bys jí totiž pochopil, použil bys tvar

Kód: [Vybrat]

dokud voda nevře

Co je na to spatně/nepochopeného že cyklus je jen podmíněný skok na začátek?
Algoritmicky je to ekvivalent.

7

Sítě / Re:Populárně naučná literatura pro záčínajícího síťaře

« kdy: 09. 01. 2026, 20:33:19 »

Kukaččí vejce 

8

Sítě / Re:Ping broadcastem na všechna rozhraní

« kdy: 14. 10. 2025, 13:09:22 »

Kód: [Vybrat]

# Get all interface names once
interfaces=$(ip link show | grep -E '^[0-9]+:' | cut -d: -f2 | tr -d ' ')

# Send broadcast ping on each interface
for interface in $interfaces; do
    if [ "$interface" != "lo" ]; then
        echo "Pinging on interface: $interface"
        ping -I $interface -b 255.255.255.255 -c 3
    fi
done


9

Studium a uplatnění / Re:Jak na angličtinu?

« kdy: 26. 08. 2025, 16:08:20 »

Tak základ jsou samozřejmě slovíčka. Ty se člověk naučí když je používá, nebo naslouchá. Ale co s nimi, že?

Pro mě bylo hodně důležité rozumět pořadí slov ve větě. Narozdíl od češtiny je v angličtině systém pořadí slov ve větě. SVOMPT = Subject Verb Object Mean Place Time. Doporučuju analyzovat anglické věty a najít v nich tyto katergorie. Pak člověk pochopí jak skládat věty, nebo jak rozluštit i to nejdelší souvětí.

Většinou je problém že se lidi snaží překládat českou větu do angličtiny slovo od slova. To je špatně.

Dále je hodně důležité naučit se naslouchat a rozumět - nepřekládat si to v hlavě, ale rovnou tomu rozumět. Když si to člověk překládá v hlavě během toho co někdo mluví, tak ztratí nit.

Dále je podle mě hodně dobré naučit se veškeré různé reakce, co používám v češtině, i v angličtině. Každý má nějaký styl řeči a nějak reaguje když mu kolega, nebo někdo jiný, něco něco říká. Třeba "no nekecej", "to snad ne", "to jako fakt?" atd... tak takové reakce by se měl člověk naučit i v angličtině aby mohl přirozeně reagovat když se s někým baví. Když se to člověk naučí, nemusí pak uměle kopírovat nějaké naučené fráze ale je prostě přirozený.

No a ohledně časů, angličtina jich má hodně, ale nejdůležitější pro lajka je rozumět, že u časů existují varianty prostý/průběhový. Třeba v češtině se řekne jinak "chodím do práce" a "jdu do práce" (používáme pro to jiné slovo chodím/jdu) ale obojí je "jít + práce" (go + work). Jedno znamená že teď tam zrovna jdu a druhé že práci mám, čili tam chodím. V angličtině to, že práci mám, vyjádřím přítomným prostým. "I go to work" - neznamená to že teď tam jdu, ale že tam pravidelně chodím. Kdežto "I am going to work" - znamená že teď tam zrovna jdu - jsem na cestě do práce.

Když k tomu člověk ještě přidá předpřítomný čas, který se používá v angličtině často, tak už na tom bude hodně dobře. Oba dva časy (minulý i předpřítomný) označují něco co se stalo v minulosti, ale rozdíl je v tom co chce mluvčí zdůraznit.

Když si člověk osvojí základní tři časy, jejich 2 varianty a k tomu předpřítomný čas, tak už podle mě dokáže rozumět nebo říci téměř čemukoliv/cokoliv.

10

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 15:06:01 »

Já když říkám že píšu v C, tak mluvím o syntaxi jazyka. Že ty v tom vidíš standard a nedokázal bys napsat driver který musí zapsat na adresu 0 protože bys měl panickou hrůzu že to je undefined behaviour, to je tvoje mínus. Já jsem pragmatik a flexi. Kde to jde tak píšu portabilní kód, kde to nejde tak platform specific. A jestli tomu říkáš že nepíšu v C, tak si tomu tak říkej, je mě to celkem šumák. Asi vlastně nemám dále co bych tady k diskuzi přispěl, jsem diskvalifikován se o C vůbec bavit, protože dělám embedded věci. Oukej.

Ale to se týká i embedded. I v embedded musíš řešit, že je dereference null pointeru undefined behavior. Dám ti praktický příklad. Jsou mikrokontroléry, které mají RAM v paměťové mapě od adresy 0, takže adresa 0 je naprosto validní pointer do RAM. Co s tím? Vyřeší se to tak, že se RAM zadefinuje od adresy 1 a adresa 0 se ignoruje, abychom se vyhnuli problémům s dereferencí null pointeru. Přijdeme o jeden bajt RAM na mikrokontroléru, ale to je nízká cena za vyřešení problémů s adresou 0 a undefined behavior.

Jenže na té adrese může být registr která má nenahraditelnou speciální funkci či význam. To je naprostý nesmysl to řešit tak jak říkáš. To může udělat jenom teoretik který k tomu prakticky nikdy nečmuch.

Normálně se otestuje překladač zda to podporuje a když ne, tak se vybere jiný. Takhle se to v praxi řeší.
Případně se použije inline assembler.

Těžko očekávat že nejaký kód handlující absolutní adresy registrů se bude někam přenášet. Proto je undefined behaviour úplně jedno.

11

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 14:37:33 »

Zápis přes pointer na adresu v paměti je naprosto standardní věc v C. To jenom ty zase musíš vytahovat nějaké speciality jako adresa 0 abys ukázal že jsi věčný troublemaker. Good job

Já jen cituji C standard, kde je explicitně uvedeno, že dereference null pointeru je undefined behavior. Rozumím tomu, že C standard nemáš přečtený a nevíš to. Nerozumím ale tomu, proč si pořád v opozici a snažíš se tvrdit, že zápis na jakoukoliv adresu přes pointer je v pohodě? Není to v pohodě, zápis na adresu 0 je dle C standardu undefined behavior. Ve chvíli, kdy to uděláš, tak od toho C standard dává ruce pryč a takový program může dělat cokoliv.

Já když říkám že píšu v C, tak mluvím o syntaxi jazyka. Že ty v tom vidíš standard a nedokázal bys napsat driver který musí zapsat na adresu 0 protože bys měl panickou hrůzu že to je undefined behaviour, to je tvoje mínus. Já jsem pragmatik a flexi. Kde to jde tak píšu portabilní kód, kde to nejde tak platform specific. A jestli tomu říkáš že nepíšu v C, tak si tomu tak říkej, je mě to celkem šumák. Asi vlastně nemám dále co bych tady k diskuzi přispěl, jsem diskvalifikován se o C vůbec bavit, protože dělám embedded věci. Oukej.

12

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 14:06:27 »

Píšu v C. Kde mám platform/compiler specific věci, tak použiju #ifdef a do poslední #else větve dám error "not implemented" a nechám toho kdo to někdy bude v budoucnu potřebovat, aby ty #else větve dopsal. Nebudu paralyzovat celý vývoj jenom kvůli tomu abych všem linuxákům vyhověl. Za to mě zákazník neplatí.

Nepíšeš v C. Ve chvíli, kdy uděláš dereferenci null pointeru nebo jiné undefined behavior, tak od toho C standard dává ruce pryč. Na některých platformách takové věci můžou dávat smysl, ale vždy musíš explicitně zdůraznit, že se jedná o platformově závislou věc, kterou musíš speciálně řešit, např. nějakými flagy překladače. Ty to tady prezentuješ jako něco normálního, ale děláš je pravý opak, pohybuješ se mimo C stadard a musíš to záplatovat nějakými ohýbáky.

Nesmysl. Zápis přes pointer na adresu v paměti je naprosto standardní věc v C. To jenom ty zase musíš vytahovat nějaké speciality jako adresa 0 abys ukázal že jsi věčný troublemaker. Good job

13

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 13:49:21 »

To mě ale nezajímá, mě zajíma jaký bude strojový kód a co program dělá a jestli dělá to co chci.

V pořádku, ale neříkej potom, že píšeš v C. Nepíšeš totiž v C, ale v nějakém vrid dialektu, kdy jsou tvoje programy funkční jen s konkrétním nastavením překladače na konkrétní platformě.

Píšu v C. Kde mám platform/compiler specific věci, tak použiju #ifdef a do poslední #else větve dám error "not implemented" a nechám toho kdo to někdy bude v budoucnu potřebovat, aby ty #else větve dopsal. Nebudu paralyzovat celý vývoj jenom kvůli tomu abych všem linuxákům vyhověl. Za to mě zákazník neplatí.

14

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 13:41:09 »

Prostě si překladač nastavím jak potřebuju.

Můžeš prohlásit, že dereference pointeru není undefined behavior. Můžeš i zkusit donutit překladač, aby při dereferenci null pointeru dělal něco definovaného. Nemáš pak ale validní C program. Máš program, který je dle C standardu nefunkční, standard říká, že nedefinuje jeho chování.

To mě ale nezajímá, mě zajíma jaký bude strojový kód a co program dělá a jestli dělá to co chci.

15

Vývoj / Re:Je jazyk C skutočne ťažký?

« kdy: 11. 06. 2025, 13:20:06 »

To nema s GCC nic společného. Takhle se psalo jestě než nějaký GCC vůbec existoval. A ani to nemá nutně nic společného s adresou 0. Prostě obecně když mám pointer a přectu přes něj nebo zapíšu, tak čtu nebo zapisuju z nějaké adresy v paměti která odpovídá hodnotě pointeru. Tady nic nestandardního není.

Pořád tomu nerozumíš. Nevadí, zkusím to vysvětlit znovu. null pointer (adresa 0) se v C standardu ošetřuje speciálně. C standard explicitně říká, že dereference null pointeru je undefined behavior. Tozn. pokud máš v C programu čtení nebo zápis adresy 0, překladač s tím může udělat cokoliv (a taky dělá). Může to ignorovat, může vygenerovat neplatnou instrukci, může to dokonce i fyzicky provést. Jakékoliv chování, včetně všech zmíněných, je při dereferenci null pointeru legální.

Já tomu rozumím a chápu to. Já jenom nechápu co s tím máš za problém. Prostě si překladač nastavím jak potřebuju. Když píšu driver nebo knihovnu pro MCU kde tam potřebuju opravdu zapsat, tak si to tak nastavím. Když píšu program běžící v rámci OS tak to samozřejmě nechám generovat ud2 instrukci abych to odchytil v debuggeru. To že přes pointer se dá zapisovat na adresu a že toto je platné v C všude stále platí. Hodnota 0 může být speciálně handlovaná překladačem, ale to je optional. Tak samo ale může být potřeba vytvořit program který to cíleně dělá a překladač by to měl umožnit (alespoň nějakým přepínačem jako to má GCC).