Je jazyk C skutočne ťažký?

[HermaneusMora]

Ccko, narozdil od mnoha vsemoznych frikulinksych kravovin, po kterych za par let pes nestekne, dela presne to, co napises.

Jenže pokud nejsi velmi zkušený programátor, tak to znamená, že to velmi často dělá něco jiného, než chceš.

[Reklama]

[xyz]

Ccko, narozdil od mnoha vsemoznych frikulinksych kravovin, po kterych za par let pes nestekne, dela presne to, co napises.

Jenže pokud nejsi velmi zkušený programátor, tak to znamená, že to velmi často dělá něco jiného, než chceš.

Nerozumim. Muzes dat nejaky priklad? Proc by mel delat _velmi casto_ neco jineho nez chci, kdyz ten jazyk je jednoduchy?

[Zopper]

Ccko, narozdil od mnoha vsemoznych frikulinksych kravovin, po kterych za par let pes nestekne, dela presne to, co napises.

Jenže pokud nejsi velmi zkušený programátor, tak to znamená, že to velmi často dělá něco jiného, než chceš.

Nerozumim. Muzes dat nejaky priklad? Proc by mel delat _velmi casto_ neco jineho nez chci, kdyz ten jazyk je jednoduchy?

V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

[radioing]

Není to jedinná varianta. Lze definovat makro a na platforme ktera nepodporuje signed aritmetic right shift se da jeho chovani simulovat.

Tak to jste me s tim test_sars pekne nahlodal. Mam ve sve helper knihovne tuto variantu

Kód: [Vybrat]

int asr(int x, int n)
{
    return (x >= 0) ? (x >> n) : ((x >> n) | (~((~0U) >> n)));
}
ktera je nezavisla na posuvu (arith/log), presne z toho duvodu, ze jsem nenasel elegantni zpusob, jak v compile time detekovat implementaci >>. Optimalizace v gcc i clang si s tim neporadi a konci to vzdy na sar + shr. Nastesti jsem to nikdy nepotreboval.

[František Ryšánek]

Já bych možná jen zmínil, že přestože jsem tu a tam historicky něco malého napsal, zhusta v céčku, tak shift na signed integer jsem co pamatuju nikdy nepotřeboval :-) takže ponaučení původnímu tazateli: jestli chcete tak se céčka bojte, ale ne kvůli shiftu se znaménkem :-)

[Reklama]

[Radek Miček]

V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

Mnohdy používají jen zbytečně komplikovaný přístup, kdy alokace spravují jednotlivě místo toho, aby to dělali hromadně.

Kdyby ten kód napsali jednodušeji, tak by měli méně problémů.

[BoneFlute]

V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

Mnohdy používají jen zbytečně komplikovaný přístup, kdy alokace spravují jednotlivě místo toho, aby to dělali hromadně.

Kdyby ten kód napsali jednodušeji, tak by měli méně problémů.

A není to náhodou právě to, o co jde? Jazyk, který tě prostřílí jak řešeto jen proto, že nejsi dost dobrej...?

[Ink]

V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

Mnohdy používají jen zbytečně komplikovaný přístup, kdy alokace spravují jednotlivě místo toho, aby to dělali hromadně.

Kdyby ten kód napsali jednodušeji, tak by měli méně problémů.

Existuje na to nějaký dokument, který by popisoval "best practice" v takových případech? Ideálně s poukázáním na konkrétní historické incidenty?

[Radek Miček]

V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

Mnohdy používají jen zbytečně komplikovaný přístup, kdy alokace spravují jednotlivě místo toho, aby to dělali hromadně.

Kdyby ten kód napsali jednodušeji, tak by měli méně problémů.

Existuje na to nějaký dokument, který by popisoval "best practice" v takových případech? Ideálně s poukázáním na konkrétní historické incidenty?

Nevím o tom.

Sám za sebe bych řekl: (1) preferovat statickou alokaci, (2) pokud nejde statická alokace preferovat arena alokátory nebo pooly, (3) pokud do nějaké struktury dávám ukazatel, tak ta struktura by neměla mít delší životnost než to, na co ukazuje ukazatel, (4) místo ukazatelů používat handly (z článku Handles are the better pointers), zejm. pokud si nejsem jistý životností objektů.

[BoneFlute]

V CVE databázích je těch příkladů je spousta. Pokud to ani projekty jako Linux Kernel nebo GNU Coreutils nedokážou nedělat chyby při práci s pamětí, tak tím hůř se tomu ubrání někdo bez spousty praxe a citu.

Mnohdy používají jen zbytečně komplikovaný přístup, kdy alokace spravují jednotlivě místo toho, aby to dělali hromadně.

Kdyby ten kód napsali jednodušeji, tak by měli méně problémů.

Existuje na to nějaký dokument, který by popisoval "best practice" v takových případech? Ideálně s poukázáním na konkrétní historické incidenty?

Nevím o tom.

Sám za sebe bych řekl: (1) preferovat statickou alokaci, (2) pokud nejde statická alokace preferovat arena alokátory nebo pooly, (3) pokud do nějaké struktury dávám ukazatel, tak ta struktura by neměla mít delší životnost než to, na co ukazuje ukazatel, (4) místo ukazatelů používat handly (z článku Handles are the better pointers), zejm. pokud si nejsem jistý životností objektů.

Co mi to jen připomíná...

[Jiří Havel]

Ccko, narozdil od mnoha vsemoznych frikulinksych kravovin, po kterych za par let pes nestekne, dela presne to, co napises.

Jenže pokud nejsi velmi zkušený programátor, tak to znamená, že to velmi často dělá něco jiného, než chceš.

Nerozumim. Muzes dat nejaky priklad? Proc by mel delat _velmi casto_ neco jineho nez chci, kdyz ten jazyk je jednoduchy?

Tak schválně, co dělá tenhle nevinně vypadající kus kódu :

Kód: [Vybrat]

    for (int i = 0; i < 4; ++i)
        printf( "%d\n", i*1000000000 );

Odpověď zní že se může stát úplně cokoliv. V závislosti na platformě, překladači, náladě nosních démonů a fázi měsíce třeba :
- Vypíše to 4 čísla, které by člověk čekal. (obvykle debug, nebo staré překladače)
- Přeloží se to na nekonečnou smyčku. (novější překladače s optimalizacema)
- Vyoptimalizuje se to do pryč a vezme to ssebou půl programu. (pro tenhle konkrétní kód jsem to teda nepozoroval, ale je to legální a zažil jsem něco dost podobného)

Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk. 

[Pavel Stěhule]

Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk. 

Když to přeložím bez optimalizací - na gcc 15.1, vypíše to 4 čísla. Když to zkusím s optimalizací

dostanu zřetelný warning:

<code>
    test.c: In function ‘main’:
    test.c:7:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
        7 |         printf( "%d\n", i*1000000000 );
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test.c:6:20: note: within this loop
        6 |  for (int i = 0; i < 4; ++i)
          |                  ~~^~~
</code>

[Pavel Stěhule]

Zkus tohle chování vysvětlit. Pokud možno _jednoduše_, když je C jednoduchý jazyk. 

Když to přeložím bez optimalizací - na gcc 15.1, vypíše to 4 čísla. Když to zkusím s optimalizací

dostanu zřetelný warning:

<code>
    test.c: In function ‘main’:
    test.c:7:9: warning: iteration 3 invokes undefined behavior [-Waggressive-loop-optimizations]
        7 |         printf( "%d\n", i*1000000000 );
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    test.c:6:20: note: within this loop
        6 |  for (int i = 0; i < 4; ++i)
          |                  ~~^~~
</code>

Je to docela dobře vysvětlené https://stackoverflow.com/questions/24296571/why-does-this-loop-produce-warning-iteration-3u-invokes-undefined-behavior-an .

Holt optimalizace v C jsou opravdu agresivní - a opravdu se v Cčku nevyplatí ignorovat warningy

[linuxak]

Je to docela dobře vysvětlené https://stackoverflow.com/questions/24296571/why-does-this-loop-produce-warning-iteration-3u-invokes-undefined-behavior-an .

Holt optimalizace v C jsou opravdu agresivní - a opravdu se v Cčku nevyplatí ignorovat warningy

Optimalizace založené na undefined behavior jsou, řekněmě, tak trochu za hranou. Formálně takovým optimalizacím nic nebrání (je to undefined, takže překladač může udělat cokoliv), nicméně obvykle nechceme, aby program dělal cokoliv. Nedávno vyšla docela hezká studie:

Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact

A její závěr je celkem jednoznačný: The results show that, in the cases we evaluated, the performance gains from exploiting UB are minimal. Furthermore, in the cases where performance regresses, it can often be recovered by either small to moderate changes to the compiler or by using link-time optimizations.

Konkrétně signed integer overflow zkoumají pod AO3 (vypnuli to pomocí -fwrapv) a rozdíly ve výkonu jsou zanedbatelné.

[Pavel Stěhule]

Konkrétně signed integer overflow zkoumají pod AO3 (vypnuli to pomocí -fwrapv) a rozdíly ve výkonu jsou zanedbatelné.

Ono je otázkou, co je dneska implementovatelné v překladači z pohledu zpětné kompatibility a očekávání uživatelů.

V každém případě moderní překladač důrazně upozorní, že je něco jinak, a je na vývojáři aby napsal kód bez warningu. V Postgresu kód s warningem nemá šanci se dostat do upstreamu, a co jsem se jako vývojář naučil, že warning v Cčku není něco, nad čím by se dalo mávnout rukou.