Jaderné noviny - 1. 9. 2016: Pohled do hlavy vývojářky Coccinelle (diskuse)

[Michal Kubeček]

Docela mne překvapuje, že někdo opravdu napíše

  !x & y

s tímhle mezerováním, pokud tím chce říct, že se negace vztahuje na výsledek &.

V tomto případě bych byl navíc s automatickým opravováním hodně opatrný, protože jakkoli je "!x & y" logický nesmysl, nedivil bych se, kdyby některé výskyty byly ve skutečnosti překlepem v

  !x && y

[chrono]

Hľadajú sa tam ale prípady, keď je y konštanta (takže áno, môže to nájsť aj nevhodný kód, ale takých chybne nájdených miest nebude až tak veľa, aby to pri kontrole spôsobovalo príliš veľa problémov).

[Michal Kubeček]

Aha, jasně, s konstantou to "&&" moc časté nebude, nanejvýš nějaké CONFIG_* IS_ENABLED(). Na druhou stranu tak ale nechytne případy, kdy druhý operand konstatní není.

[Josef Kufner]

Spíš jde o to, že grep to neumí najít, takže seznam pro ruční kontrolu je moc dlouhý.

[Bedňa]

Ideálne by bolo impementovať "no idiot syntax", pretože v Cečku ide napísať nezmyselných konštrukcií kopec a upozorňovať na ich výskyt.

[Josef Kufner]

gcc má nějaká varování, že chce třeba extra závorky kolem přiřazení v ifu.

[Bystroushaak]

Ideálne by bolo impementovať "no idiot syntax", pretože v Cečku ide napísať nezmyselných konštrukcií kopec a upozorňovať na ich výskyt.

Jen jestli by ti pak z C něco zbylo :>

[pc2005]

Tak současný nejmenší turing univerzální "jazyk" je tuším Wolfram (2,3) .

[Bedňa]

Keď som koment odoslal, tak mi tiež dopalo, že nad nadstavbou asembleru je ťažko písať nejakú kontrolu. Takže súhlas.

[Bystroushaak]

Tak kontrola by se určitě dala. Co by bylo ale lepší je třeba nějaká ne-tak-dementně parsovatelná syntaxe a strojově parsovatelné a pochopitelné chybové hlášky. Dneska třeba když chceš generovat z nějakého svého jazyka / projektu C kód, tak to sice funguje, ale nedosahuje to toho potenciálu třeba co do různých transformací a úprav, protože ten jazyk je prostě místama zbytečně komplexní.

[tom]

jakkoli je "!x & y" logický nesmysl

A to jako proc? Co treba todle:

for (i = 30; i > 0; i--) {
  x = function_returning_error_code();
  printf("%s; ", !x << i & report_pass_mask ? "pass" : "----");
}
x = function_returning_error_code();
printf("%s\n", !x & report_pass_mask ? "pass" : "----");

[Michal Kubeček]

1. Bez toho, abyste té funkci aspoň předal číslo testu, to moc smyslu nedává.

2. Abyste tam dostal tu konstrukci, musíte úplně zbytečně vytáhnout jednu iteraci mimo smyčku. Zhoršení čitelnosti, riziko zavlečení chyby, …

3. Stejně křečovité a samoúčelné je použití "!x << i & mask" místo přirozenějšího a čitelnějšího "!x && (mask & BIT(i))"

4. A to nás přivádí k otázce, zda ty testy, na jejichž výsledku nezáleží, vlastně vůbec chceme spouštět. )

[tom]

1. Bez toho, abyste té funkci aspoň předal číslo testu, to moc smyslu nedává.

Treba ta funcke pouziva globalni promenou, jedna se o priklad, nechapu, proc to resite.

2. Abyste tam dostal tu konstrukci, musíte úplně zbytečně vytáhnout jednu iteraci mimo smyčku. Zhoršení čitelnosti, riziko zavlečení chyby, …

Prvni a nebo posledni iterace se vytahuje celkem bezne, protoze byva jina. V existujicim kodu jich najdete spousty, ilustroval jsem to na prikladu odlisneho formatovani posledni hodnoty.

3. Stejně křečovité a samoúčelné je použití "!x << i & mask" místo přirozenějšího a čitelnějšího "!x && (mask & BIT(i))"

Syntakticky i semanticky je to spravne, tudiz to nemuze byt logicky nesmysl a to tu jde. Krecovitost je subjektivni.

4. A to nás přivádí k otázce, zda ty testy, na jejichž výsledku nezáleží, vlastně vůbec chceme spouštět. )

Jedna se o priklad, chtel jsem ho ponechat co nejjednodussi, abych vam usnadnil jeho pochopeni. Bohuzel se mi to nepovedlo.

[Michal Kubeček]

Pokud chcete ukázat příklad, měl by to být takový, u kterého jsem schopen uvěřit, že to někdo příčetný takto opravdu napíše (a bude k tomu mít jiný důvod, než že chce za každou cenu ukázat, že tu konstrukci použít lze). Pokud bude šance, že někdo příčetný takový kód akceptuje, tím lépe. Při nejlepší vůli vaši ukázku za takový příklad považovat nemůžu.

[tom]

Tvrdil jste, ze dana konstrukce je logicky nesmysl, poslal jsem vam priklad, ktery je jak semanticky tak syntakticky spravne, na ilustraci toho, ze nemate pravdu. A clovek to psat ani nemusi, kod generuji i stroje a to je presne misto, kde jsem se s tim setkal.

[lubo]

Nemam prehlad v programovani v jazyku C, tak ma prosim ospravedlnte za krepu otazku, ale to neexistuje IDE (devcpp, eclipse, intelij, visualstudio,...), ktore by zvladlo napriklad ten prechod na nove api a preklopilo by to i drajvre? Osobne si bez funkcii ako premenovat, pridat parameter, prehodit poradie parametrov a podobne moc neviem predstavit spravovat nejaky kod (java/scala) po dlhsiu dobu...

[mimi.vx]

ano .. rika se mu programator, developer nebo vyvojar

 

a ano, tady se nepise o takove samzrejmosti jako je refactoring ..

[Sid]

No tento komentar vyssie by bol zjavne "ozdobou" LKML . Tusim nastal cas aby sa IDE niekomu spustalo iba po predlozeni dokladu o sposobilosti rozmyslat.

[smazáno]

to "java/scala" si uz psal nemusel, to nam bylo jasne po precteni prvni vety :-P

[Pavel Stárek]

Problém je, že u kernelu se velice rychle mění jeho vlastní API a to bohužel i v setinkových verzích. Pamatuji případ, že například Nvidia ovladače šly v pohodě zkompilovat na kernelech 3.0 až 3.18 a pak vyšel kernel 3.19 a už najednou nešly, protože se změnil název jakési funkce v kernelu. Ano, souhlasím s tím, že toto by si měli hlídat hlavně vývojáři Nvidie, ale prostě minimálně u longterm kernelů by API mělo být zachováno po celou dobu životnosti (možná dokonce je, věci okolo jádra moc nesleduji).

[Michal Kubeček]

u kernelu se velice rychle mění jeho vlastní API a to bohužel i v setinkových verzích

To je hlavně hluboké nepochopení toho, co ty verze (ne)znamenají. Přechod mezi 3.19 a 4.0 nebyl (až na rozbití pár neprozíravých skriptů) o nic významnější než třeba právě mezi 3.18 a 3.19.

Ano, souhlasím s tím, že toto by si měli hlídat hlavně vývojáři Nvidie

Každý svého štěstí strůjcem. Když se někdo rozhodne poskytovat closed source out of tree driver a někdo jiný na něj spoléhat, je to jejich volba, ale musejí počítat s následky.

ale prostě minimálně u longterm kernelů by API mělo být zachováno po celou dobu životnosti

Jak to souvisí s tím, jestli se změnilo mezi 3.18 a 3.19?

[Pavel Stárek]

Souvisí to s tím, že by se u lt kernelu nemělo rozbít API například mezi verzí 4.4.18 a 4.4.19, ale jak píšu, nejsem v jádře zase tak kovaný, takže tomu tak třeba je již dnes.

[trekker.dk]

Souvisí to s tím, že by se u lt kernelu nemělo rozbít API například mezi verzí 4.4.18 a 4.4.19

Proč by ne? LT jádro znamená, že aktualizace přinášejí téměř výhradně opravy chyb a že by se jeho nasazením nemělo nic rozbít. "Nic rozbít" se ale - jako vždy - vztahuje pouze na in-tree kód. Pokud někdo používá out-of-tree ovladače, to už je napsáno o dva příspěvky výš...

[Jendа]

ale prostě minimálně u longterm kernelů by API mělo být zachováno po celou dobu životnosti (možná dokonce je, věci okolo jádra moc nesleduji)

No to je. Longterm je třeba 3.14.x. 3.x je normální další verze a 4.0 se od 3.19 neliší nijak víc než 3.19 od 3.18. Už 10 let se na major a minor verze nehraje.

[Ondrej Santiago Zajicek]

No, je trochu matouci pouzivat 'API' pro oznaceni ciste interniho rozhrani. Interni rozhrani se v Linux kernelu obecne meni, (Vnejsi) API zustava stabilni.

[Ladislav Hagara]

Jaderné noviny jsou z 1. 9. O týden později byl zveřejněn Videozáznam přednášky Pohled do hlavy vývojářky Coccinelle.