Vlákno názorů k článku Jsou vaše peníze u Citibank v bezpečí? od Michal Kubeček - Tohle zrovna není dobrý příklad, pokud píšete programy s...

Tohle zrovna není dobrý příklad, pokud píšete programy s přesvědčením, že překladač vyhovuje normě, pak si chyby ani nevšimnete (protože vás vůbec nenapadne tu proměnnou za cyklem použít).

Řídící proměnná je iterátor - je to prostě jednoduchá implementace iterátoru. Proto jsem vás chtěl dostat k tomu, že i a j jsou řídící proměnné.

Ale ono je to ještě jinak a teď mi to došlo. To co je v závorce za "for", je implementace iterátoru. Takže iterátor není i nebo j, ale celý obsah té závorky.

Takže vám ctění kolegové dávám za pravdu a děkuji za objasnění. Když se na to člověk umí dívat takto, je použití cyklu for v podobě uvedené v článku přehledné.

Pro velmi jednoduché iterátory je skutečně rozumné používat zápis:

for (iterátor)
příkaz

A pokud je to zvláště jednoduchý případ

for (i = 0;i < 10;i++)
příkaz

můžeme i považovat za iterátor a tedy i za řídící proměnnou - a není to nesmysl a není to "zatěžování hlavy".

Nebyl bych si tak jistej tou prvni nahradou - co kdyz je i float, ne integer?

Ne, ja se jenom s vama hadam, ze for je pouzitelny a vhodny i bez ridici promenne. ;-)

Ikdyz v tomto pripade samozrejme o inkrementovani nejake promenne v principu jde.
Ale dovedu si rovnez predstavit daleko slozitejsi cykly for a urcite jsem je nejednou pouzil.
for v C/C++ zkratka neni synonymem pascalovskeho cyklu for, o dalsich jazycich nemluve...

Takže i a j ve zde diskutovaném příkladu jsou iterátory?

S tim ja nesouhlasim. Bezne se v C++ pouzivaji iteratory stylem

for (iter.start(); !iter.done(); iter.next()) {
...
}

a prijde mi to daleko prehlednejsi nez to delat pomoci while.

No bezva, takže souhlasíte s tím, že cyklus for v podání C je jenom komplikovanější a nesrozumitelnější způsob zápisu cyklu while (i ta podmínka není vlastně "ukončovací", ale "pokračovací", protože dokud platí - while - cyklus pokračuje).

Takže když vyslovím hypotézu, že cyklus for je vhodné používat jenom tehdy, když máte nějakou řídící proměnnou, tj. nějaký counter, který inkrementujete nebo dekrementujete - budete s tím souhlasit?

Ano, je to jinak a posledni verze (no.13) od jedne nejmenovane firmy to ma konecne spravne ;-)

> Ukončovací podmínku mají i jiné cykly, než for. Čím se tedy liší for od jiných typů cyklu?

Na to je jednoduchá odpověď: ničím ;-), resp. liší se pouze syntaxí,
tedy tím, že je to všechno pohromadě, nicméně ekvivalentí zápis uděláte i pomocí while() { }

> Čím se liší "část výkonná" od "samotného těla cyklu"?
Tím, že je to všecho hezky nahoře pohromadě.

> Není náhodou tato "část výkonná" jenom "koncem samotného těla cyklu"?
ANO

> Není náhodou "samotné tělo cyklu" jenom "něčím, co se nemůže dát do části výkonné, aby alespoň něco bylo v samotném těle cyklu a specifikaci bylo učiněno zadost"?

Nejspíš ne, protože přes operátor "," (čárka) asi nepůjde udělat úplně všechno... i když mě zrovna teď nic nenapadá ;-), ale co si budem povídat byl by to hnus... ;-)

Navíc do části výkonné by měly přijít pouze jednoduché věci, které ovlivňují chod cyklu... (z hlediska přehlednosti kódu.)

O.

No, ono je asi špatně hlavně to, že tohle všechno musíte vědět, abyste s tím mohli rozumně pracovat. Proto je programování takový problém, jaký je. (A neříkejte, že není. :-)

Hm, máte pravdu, j se mělo inicializovat na hodnotu 1, tam mám chybu. Jenomže to jenom ilustruje, jak je ten původní zápis nepřehledný.

Ukončovací podmínku mají i jiné cykly, než for. Čím se tedy liší for od jiných typů cyklu?

Čím se liší "část výkonná" od "samotného těla cyklu"?

Není náhodou tato "část výkonná" jenom "koncem samotného těla cyklu"?

Není náhodou "samotné tělo cyklu" jenom "něčím, co se nemůže dát do části výkonné, aby alespoň něco bylo v samotném těle cyklu a specifikaci bylo učiněno zadost"?

Mozna je chyba prave v tech "predpotopnich" null-terminated stringach v Ccku ;-)

Ohledne 'Borland Pascalu' - dnesniho Object Pascalu (Delphi 6) je hodnota promenne pouzite ve smycce na konci nedefinovana (viz dokumentace). Pri pokusu o pouziti teto promenne po skonceni smycky dostanete pri kompilaci warning: [Warning] xxx: FOR-Loop variable <name> may be undefined after loop

Az na kompilatory jedne nejmenovane firmy, kde ma promenna i platnost i po skonceni cyklu. Ale mozna uz to je v nove verzi jinak.

Ekvivalentní to není, test, jestli je i různé od nuly (nebo kladné) je jedna instrukce, na test zda je i různé od z (nebo menší než z) potřebujete dvě. Před tím je totiž musíte dát ještě test. Nehledě na to, že můžete na x86 použít přímo instrukci loop, která je opět o něco rychlejší.

mas pravdu, vse na cem zalezi je ORACLE PL/SQL, bizuterie okolo je Delphi, MSVC, Perl, ...

No je to sice dost off-topic, ale prinejmensim na i80x86 to neni pravda. Scitani je stejne rychle jako odcitani.

Ta prvni nahrada ma byt samozrejme i = 10; Ach jo. Jeste ze zrovna nepisu optimalizator...

Zapomente na pojem ridici promenna cyklu, v C nic takoveho neni. Jen ukoncovaci podminka cyklu. Optimalizator muze v zasade cokoli, ale nesmi zmenit smysl kodu. Takze napriklad:

for ( i = 0; i < 10; ++i ) ;

muze nahradit jako

i = 9;

Vas priklad samozrejme take, ale ne vzdy:

for ( i = 0; i < z; ++i ) {
if (Something[i]) {
break;
}
}

by mel prochazet vzdy od zacatku. Aspon doufam :-)

Hodnoty promennych po ukonceni cyklu maji spravnou hodnotu a bezne se pouzivaji. Vyjimkou je C++:

for ( int i = 0; i < N; ++i ) {
...
}

kde promenna i neni mimo telo cyklu pristupna. Bohuzel, spravne to umi az nejnovejsi verze prekladacu, starsi pristup umozni.

(hmm, proc to zere mezery na zacatku radku?)

no vy jste tomu pomohl! zatimco v puvodni verzi byla jasne oddelena cast inicializacni, cast podminkova, cast vykonna a samotne telo cyklu, tak vy jste je pomichal a udelal z toho gulas, cehoz dukazem je i to, ze vas cyklus pocita chybne j - misto od 0 ho pocita od 1. jinak zapomente na to, ze by for v cecku melo nejakou ridici promennou - s tim si nema cenu trapit hlavu, for ma proste ukoncovaci podminku, ktera byla i v te puvodni verzi jenom jedna. jedine co bych te puvodni verzi vytknul by bylo na muj vkus prilisne setreni mezerami.

O použití uvnitř cyklu jsem psal v souvislosti s otočením směru iterací (je pravdou, že na to, abych si to mohl dovolit, potřebuji řídící proměnnou nepoužít nejen během, ale ani po skončení cyklu).

Jinak uvedená ukázka je názorným příkladem toho, že mluvit u cyklu for v C/C++ o nějaké řídící proměnné obecně dost dobře nejde.

A přitom není problém dodržovat pár základních pravidel, případně
si napsat nějaký/použít wrapper na práci s řetězci a je to ;-).

U jazyků platformě nezávislých (tedy interpretovaných ať už je to bytecode nebo přímo zdroják) zase hrozí nebezpečí v implementaci interpretu a ty většinou píšou zase ony velké software houses, nicméně u lidí kteří píšou kompilátory/interprety se dá předpokládat, že na tom budou znalostně poněkud lépe... ale spolehnout se na to taky nedá...

U OpenSource se dá alespoň trochu doufat, že si ten zdroják někdo prohlídne dřív než to někdo naboří...

O.

Jasně. Mně šlo zase hlavně o to, že když někdo vyvine aplikaci v C a není to open-source, tak se pak musí snažit, aby se její kód nedostal ven, protože nějaké díry se tam najdou skoro vždycky. (On někdy stačí disassembler.)

Sice se dají stanovit normy pro psaní kódu a existují nástroje, které v kódu hledají místa podezřelá z buffer-overflow, ale stoprocentní to nikdy není.

Když se podíváte na stránky podpory velkých softwarehousů, snadno tam najdete info o podobných chybách. A týká se to i firem, které mají image prvotřídní bezpečnosti.

Tady je obrovská výhoda Javy, .NET a podobné zvěře.

Ten cyklus je spíš komprimovaný ;-), hlavně šlo o to, aby se v každé iteraci nedělal strncat().
O.

Podle mne (ale už léta v C neprogramuji) v C může programátor skutečně počítat s tím, že v řídící proměnné cyklu je během cyklu i po jeho skončení to, co předpokládá, že tam je.

Dokonce mám (už dosti matný) dojem, že s tím může počítat i v Borland Pascalu. (Což je poslední Pascal, ve kterém jsem programoval, ale to je ještě více let. :-)

(Abych opravil Michala Kubečka - Lukáš Suchánek nepsal o hodnotě řídící proměnné BĚHEM cyklu, ale PO SKONČENÍ cyklu.)

Nicméně, kód vypadá takto:

if (leng>=8000)
exit(1); /* spatna vstupni data */

for(i=vlen,j=0;i<leng; i+=16, j++)
trans[j] = str_bin[i];

trans[j] = 0;

Cyklus je natolik komprimovaný (efektivní? možná - ale optimalizátoru to asi nepomůže), že není hned vidět, že řídící proměnnou je i, nikoliv j.

Možná by bylo vhodnější to napsat takto:

j = 0;

for(i=vlen;i<leng;i+=16) {
j++;
trans[j] = str_bin[i];
}

trans[j] = 0;

Takhle je hned jasné, co se kdy provede. A je to jasné stejně tak kompilátoru, jako člověku.

Bohužel, chyby s přetečením bufferu jsou v C programech naprosto běžné. Jsou ve spoustě programů, i ve slavných "velkých" aplikacích slavných firem. Troufl bych si říct, že těžko najdete aplikaci napsanou v C o alespoň miliónu řádků, kde by nějaká taková chyba nebyla.

nejsem ani assembler guru, ale toliko si snad z hodin assembleru pamatuji, ze odcitani je rychlejsi nez pricitani, takze predpokladam, ze kompilatory podobne optimalizace delani nikoliv kvuli podmince same, ale kvuli zmene ridici promenne. Ale .. neni tohle uz diskuse na jine tema nez o jakem je clanek :-) ?

No mel jsem tu cest programovat neco nad SETem v podani MUZO, mohu rici, ze sice vysledek byl funkcni, ale asi tak 40% specifikace si musel clovek domyslet... hlavne ze to melo asi tak 40 stranek ve Wordu, prisernou typografickou upravu, spoustu vomacky a kecu okolo, ale opravdu zasadni udaje pro programatora (a ze to byl skutecne dokument zvany Reference guide for programming.... (bla bla bla..)) tam chybely...

Na druhou stranu ne ja, ale kolegove meli tu cest delat neco napr. s puvodnim Juice Eurotelu, jak se vyjadril - ani halir by pres to neposlal... zrejme vedel proc...

Takze tech radoby dokonalych bastlu v republice je daleko lepe (navic kdyz se clovek obcas dostal v techto 'velkych' firmach operujicich s minimalne stamiliony korun k tomu, jak zpracovavaji data (namatkou Komercni banka, Ceska posta), doslova a do pismene trpel uz na pohled) a skutecne cest vyjimkam. Proti eBance nemohu rici nic vice, nez ze jsem nezaznamenal uspesny hack jejich systemu, Vy ano?

Troufam si tvrdit, ze zmenit takto vyznam cyklu je mozne jen v naprosto jednoduchem pripade a ve vetsine pripadu si to kompilator nedovoli, protoze bud na to jeho inteligence nesaha a nebo zjisti, ze nesmi. Pokud bychom se nemohli spolehnout ani zakladni paradigmata tak bych tech kav denne vypil asi tolik, ze za tyden by me mohli prazit na kavu nove znacky... - jednoduse - netvrdim, ze to nikdy kompilator nevyprodukoval, ale 99% pripadu to nezbasti a nebo je v nem hodne zasadni chyba... BTW kdyz uz jsme u toho, jak se po strance taktu lisi JMP if ZERO nebo JMP if Equal (hodne chytry optimalizator to pro X (iteraci) < nez vhodna konstanta rozvede...:->)? Mne to prijde ekvivalentni, takze o jake 'optimalizaci' hovorite?

AFAIR to zrovna v C zaručeno je. Na rozdíl od třeba Pascalu. Ty optimalizace, které zmiňujete, (a mnohdy i daleko horší) kompilátor provede pouze v případě, že ví, že si to může dovolit (což je v tomto případě asi jen když to i uvnitř cyklu vůbec nepoužijete). Kdyby náhodou ne, chyba by byla na straně překladače (a programátora taky, že si toho při ladění nevšiml).

Ave,
trochu me zarazila jistota, s jakou autor clanku ukoncoval retezec na konci sve opravy:
trans[j] = 0;

Nejsem zadny C-guru a tak, pokud se mylim, me omluvte. Ziju v domneni, ze dle standardu neni jasne, jake hodnoty budou mit ridici promenne cyklu po jeho skonceni. Ve vetsine pripadu by to mohlo fungovat, ale zrovna u bankovni aplikace bych si to NIKDY netroufnul zarucit. Uz nejednou jsem se setkal s kompilatorem, ktery si for cyklus zoptimalizoval a misto for (i=0;i<z;i++) provadel v podstate for(i=z;i>0;i--) .. dusledky takove optimalizace by byly v tomto pripade fatalni a myslim, ze chyba by byla na strane programatora.

Jinak co se tyce eBanky, tak pokud se neco nezmenilo, tak jeji vnitrnosti nejsou napsany v Cecku - coz neznamena, ze tam nemohou byt daleko horsi zverstva.

/ Lukas Suchanek