Portál AbcLinuxu, 1. května 2025 06:58
longjmp
. Nebo snad v klibc
longjmp
nemají?
goto
, to jo...
goto
použít pouze v rámci funkce.
při množství věcí, které se mohou zku*vit, by skutečně muselo být skoro každé volání funkce obklopené několika úrovněmi if-ů a nevyznalo by se v tom ani to prase.
Zvlášť při dodržení coding style, který předepisuje odsazování osmiznakovým tabulátorem a limit 80 znaků na řádek. Skalním odpůrcům goto
doporučuji si nějakou funkci cvičně zkusit přepsat. Pokud by ani to nepomohlo, tak počkat půl roku a zkusit se v ní zorientovat.
pokus o alokaci prostředku 1; pokud selže goto 1; pokus o alokaci prostředku 2; pokud selže goto 2; pokus o alokaci prostředku 3; pokud selže goto 3; samotná akce; návěstí 3: uvolnění prostředku 3; návěstí 2: uvolnění prostředku 2; návěstí 1: uvolnění prostředku 1;
Jinjak ty goto v jádře typicky vypadají taktoPřesněji takto:
pokus o alokaci prostředku 1;
pokud selže goto konec;
pokus o alokaci prostředku 2;
pokud selže goto uvolni1;
pokus o alokaci prostředku 3;
pokud selže goto uvolni2;
...
uvolni2:
uvolnění prostředku 2;
uvolni1:
uvolnění prostředku 1;
konec:
return;
Je to mnohem čistší a hlavně přehlednější řešení, než kdyby se to dělalo bez goto pomocí vnořených ifů nebo pomocí opakování téhož kódu u každého selhání.
if (find ("goto", kod)) body -= 2;nikdy nepochopil a vždy jsem to bojkotoval. Já bohužel pamatuju ještě doby BASICu a pamatuju, že ani s GOTO a GOSUB to nebylo tak strašné když to nepsalo prase, které se v tom samo nezamotalo. Tendenci vnucovat programátorovi jak má psát a snažit se ho vyučovat jsem též nikdy nepochopil. Aneb nač dělat věci jednoduše, když si to můžeme zasvinit konstruktorama, destrukotama, excepšnama a bůh ví čím ještě. Vždyť GOTO se velice snadno dá přeložit na jmp instrukci, jednu z nejpřirozenějších instrukcí procesoru.
No, ono když vidíte v kódu něco na způsob
if (problém) goto label2; ... label1: úklid return 0; label2: něco goto label1; }
tak na vás přímo dýchne tak doba BASICu na osmibitech…
Tohle není kód vanilla jádra, tenhle obrat jsem viděl v jednom modulu, který ve vanilla jádře není. Prohodit pořadí nejde, protože to, co je za label2
, se nemá vykonat, pokud k němu dojdete přirozenou cestou nebo na něj skočíte odjinud. Správně by to mohlo být třeba takto:
if (problém) { něco goto label1; } ... label1: úklid return 0; }
Ale i v upstreamových projektech se občas najdou strašidelné věci. Máte-li dobrý žaludek, můžete zkusit prozkoumat třeba funkci send_dg()
v implementaci resolveru v glibc.
A mezitím budu přemýšlet, k čemu je to vlastně dobré... :)Jako hracka vazne dobre :) Ale realne pokud potrebujes hardlink na adresar, resilo by se to pomoci bind mount:
mount --bind /kdesi/cosi /nekde/jinde/cosi.
/ [/bind je prázdné] /home /var rbind / do /bind: / /bind [/bind/bind je prázdné] /bind/home /bind/var /home /var
..
", která má odkazovat na rodiče. Jenže tady by těch rodičů bylo víc, takže byste si musel některého vybrat, což zase bude dělat problémy, když zrovna tu adresářovou položku, jejíž to byl rodič, smažete.
Např. by pak byl problém s položkou "..", která má odkazovat na rodiče. Jenže tady by těch rodičů bylo víc, takže byste si musel některého vybratIMHO, vzhledem k tomu, že nic jako ".." ve FS ani není je to irelevantní - systém to vygeneruje na základě cesty, takže tenhle problém odpadá.
což zase bude dělat problémy, když zrovna tu adresářovou položku, jejíž to byl rodič, smažete.No, zatím jsem nepřišel na to, jak odstranit hardlink na adresář bez smazání obsahu :)
IMHO, vzhledem k tomu, že nic jako ".." ve FS ani není je to irelevantní - systém to vygeneruje na základě cesty, takže tenhle problém odpadá.
Co prosím? Neusuzujte, prosím, jen na základě toho, jak se (defaultně) chová příkaz cd
v bashi.
zatím jsem nepřišel na to, jak odstranit hardlink na adresář bez smazání obsahu
To není až tak překvapivé, vzhledem k tomu, že se s jejich existencí nepočítá. Musel byste si opatchovat syscall rmdir()
nebo unlinkat()
a když se zamyslíte jak, zjistíte, že není úplně triviální udělat to tak, aby to fungovalo.
ln -s vim emacs
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.