abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 10:00 | Komunita

Společnost PINE64 stojící za telefonem PinePhone, notebooky Pinebook a Pinebook Pro, IP kamerou PineCube, hodinkami PineTime, páječkou (pájecím perem) Pinecil, zdroji PinePower nebo RISC-V vývojovou deskou PineCone publikovala na svém blogu lednový souhrn novinek. Opět společně s videem (YouTube, LBRY, TILvids). Od 18. ledna bude možné objednat PinePhone s předinstalovaným Mobianem aneb Debianem pro mobilní zařízení.

Ladislav Hagara | Komentářů: 7
dnes 09:00 | Nová verze

Byla vydána nová verze 3.6 svobodného notačního programu MuseScore (Wikipedie). Představení novinek také na YouTube. Zdůrazněn je nový font Leland. Jeho představení na YouTube.

Ladislav Hagara | Komentářů: 0
včera 18:44 | Zajímavý projekt

Fedora Magazine představil projekt Fedora Kinoite aneb Fedoru Silverblue s prostředím KDE Plasma. Fedora Silverblue je neměnný systém s atomickými aktualizacemi, tj. základní systém je distribuován jako celek, s prostředím GNOME.

Ladislav Hagara | Komentářů: 2
včera 10:00 | IT novinky

Projekty Elasticsearch a Kibana, doposud distribuované pod licencí Apache 2.0, přejdou na duální licencování pod Server-Side Public License (původně používanou pro MongoDB a neschválenou jako open-source organizací OSI) a vlastní source-available licencí. Změna vejde v platnost počínaje vydáním 7.11.

Fluttershy, yay! | Komentářů: 0
včera 09:00 | Komunita

Na Humble Bundle lze do neděle 17. ledna do 19:00 získat zdarma počítačovou hru Bomber Crew (YouTube, Wikipedie) běžící také v Linuxu.

Ladislav Hagara | Komentářů: 1
včera 08:00 | Nová verze

Minimalistická linuxová distribuce Alpine byla vydána v nové stabilní řadě 3.13. Novinkou jsou např. oficiální obrazy v cloudu (AWS EC2), vylepšené síťové nástroje nebo podpora PHP 8.0.

Fluttershy, yay! | Komentářů: 0
včera 07:00 | Bezpečnostní upozornění

Uživatelé Admineru verze 3.7.1 a starších mohli být 29. a 30. prosince napadeni. Útočníkovi se podařilo do souboru jush.js, který se do této verze ještě stahoval z adminer.org, vložit kód, který mu odesílal přihlašovací údaje. Pokud jste v tomto čase tuto více než 7 let starou verzi Admineru používali, tak změňte hesla databází, ke kterým jste se přihlašovali. Novější verze ovlivněné nejsou.

Ladislav Hagara | Komentářů: 2
včera 00:11 | Zajímavý článek

Ernie Smith píše o historii populárních routerů Linksys WRT54G, jejichž software byl založený na Linuxu, a proto posléze díky GNU GPL uvolněn jako open source, což vedlo k vývoji alternativního softwaru jako DD-WRT či OpenWrt a řadě dalších využití.

Fluttershy, yay! | Komentářů: 0
14.1. 18:11 | Nová verze

Po roce vývoje od vydání verze 5.0 a více než 8 300 změnách byla vydána nová stabilní verze 6.0 softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem, Wine (Wikipedie). Z novinek lze zdůraznit core moduly ve formátu PE, Vulkan backend pro WineD3D, podporu DirectShow a Media Foundation nebo redesign textové konzole. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 4
14.1. 14:00 | Zajímavý článek

Guido Günther z Purism napsal článek Phosh Overview o uživatelském prostředí pro mobilní systémy Phosh. Přehledově popisuje co jednotlivé komponenty dělají a jak jsou propojeny.

joejoe | Komentářů: 0
Jestliže používáte distribuci CentOS, kterou náhradu plánujete vzhledem k oznámenému ukončení vydávání?
 (31%)
 (3%)
 (2%)
 (24%)
 (0%)
 (2%)
 (38%)
Celkem 145 hlasů
 Komentářů: 3, poslední 10.1. 13:01
Rozcestník

Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné

14. 1. 2013 | Luboš Doležel | Jaderné noviny | 3573×

Aktuální verze jádra. Citáty týdne: Android Authority, Linus Torvalds. Začleňovací okno verze 3.8, část druhá. Odstranění uninitialized_var().

Obsah

Aktuální verze jádra

link

Začleňovací okno verze 3.8 je stále otevřené a patche nadále proudí do hlavní řady. Přehled významných změn v 3.8 najdete níže.

Stabilní aktualizace: verze 3.0.57, 3.4.24, 3.6.11 a 3.7.1 vyšly 17. prosince. Pozor na to, že 3.6.11 je poslední aktualizací v řadě 3.6.

Citáty týdne: Android Authority, Linus Torvalds

link

Ti, kdo vyvíjejí jádra pro zařízení s Androidem vědí, jak frustrující vždy bylo portovat jádro na nové zařízení. Pokud jste téhož názoru a byli byste rádi, kdyby se tento proces zjednodušil, tak vás jistě potěší, že Linus Torvalds ohlásil podporu ARM v Linuxu.

-- Android Authority při jedné ze svých slabších chvilek

Takže počty jsou zmatené, typy jsou zmatené a jména jsou zmatená. Někdo se na to prosím podívejte, protože teď jsem i *já* zmatený.

-- Linus Torvalds

Začleňovací okno verze 3.8, část druhá

link

Linus neměl v uplynulém týdnu čas na lelkování, od přehledu z minulého týdne bylo do hlavní řady přetaženo nějakých 6200 sad změn. To celkem dělá více než 10 000 změn, což dělá z 3.8 jedno z nejživějších začleňovacích oken a vůbec první, kdy byl překročen počet 10 000. A to ještě nejsme na konci.

Do jádra se dostalo několik významných změn. Mimo jiné bylo rozhodnuto, jak bude pokračovat vývoj lepšího vyvažování NUMA. A teď už bez dalšího zdržování přehled nejvýznamnějších změn viditelných uživatelům jádra od minulého týdne:

  • Neshody kvůli tomu, jak by se měly vyřešit výkonnostní problémy NUMA, byly částečně vyřešeny tím, že Ingo Molnar souhlasil se začleněním patche „balancenuma“ od Mela Gormana, který bude sloužit jako základ pro další vývoj. Balancenuma vytváří základní infrastrukturu, jež umožní budoucí experimentování s pravidly pro umisťování a vyvažování; samo o sobě moc pravidel nepřidává. Tento základní kód byl začleněn do verze 3.8; pravidla jako taková se dostanou až do 3.9.
  • Byla začleněna funkce velké nulové stránky, což v některých případech značně sníží využití paměti.
  • Byla začleněna infrastruktura pro počítání využití jaderné paměti, což umožní určování omezení využití jaderné paměti dle řídících skupin. Více o použití této funkce najdete v dokumentaci.
  • Patch pro inline data byl začleněn do systému souborů ext4. Ext4 nyní dokáže ukládat data drobných souborů přímo v inode, což zvyšuje výkon a efektivitu využití místa na disku. Ext4 nyní také podporuje operace SEEK_HOLE a SEEK_DATA ve volání lseek().
  • Btrfs má novou operaci „replace“ (nahraď) umožňující efektivní nahrazení jedné jednotky ve svazku.
  • Systém souborů tmpfs nyní podporuje operace SEEK_HOLE a SEEK_DATA ve volání lseek().
  • Byl přetažen patch podpory uživatelských jmenných prostorů. Eric Biederman k němu říká: Tato sada změn přidává podporu toho, aby si obyčejní uživatelé mohli vytvářet uživatelské jmenné prostory a jako root takového prostoru vytvářeli další jmenné prostory.
  • Nové systémové volání:
    int finit_module(int fd, const char *args, int flags);
    lze použít k načtení jaderného modulu z daného popisovače. Toto volání bylo přidáno vývojáři ChromeOS, aby mohli přijímat nebo odmítat modul na základě toho, kde je uložený na systému souborů.
  • Síťový subsystém batman-adv získal podporu distribuované tabulky ARP.
  • Ovladače tun/tap a virtio podporují vícero front u jednoho zařízení.
  • Plánovač paketů QFQ byl upgradován na QFQ+, který je prý rychlejší a schopnější; více v tomto PDF.
  • Architektura s390 má podporu pro připojené řadiče PCI.
  • Proměnné UEFI jsou nyní přístupné přes nový virtuální systém souborů efivars.
  • Systémové volání ptrace() má novou volbu PTRACE_O_EXITKILL, které zajistí, že všechny sledované procesy obdrží signál SIGKILL, když sledující proces neočekávaně skončí.
  • Podpora nového hardwaru.

Počet interních změn je ale relativně malý. Mezi změny viditelné vývojářům jádra patří:

  • Vrstva Video4Linux2 nyní podporuje použití sdílených bufferů DMA pro I/O snímků. Více se o této funkci dozvíte z dokumentace v DocBooku. Subsystém videobuf2 pak dále podporuje použití roztroušených seznamů (scatterlist) s buffery z uživatelského prostoru v „souvislém“ režimu DMA.
  • Subsystém pro vstup podporuje použití „řízených“ zařízení přes novou funkci devm_input_allocate_device().

Jednou z funkcí, které začleněny nebyly, je podpora RAID5/6 v Btrfs. Tyto patche se aktuálně připravují pro hlavní řadu a můžeme je očekávat v cyklu verze 3.9.

Odstranění uninitialized_var()

link

Varování kompilátoru mohou být pro jaderné vývojáře spasitelem; dobré varování může pomoci předejít chybě, kterou by vývojář těžko dohledával. Vývojáře ale rychle otráví varování, která se objevují v kódu, jenž je správně. Netrvá moc dlouho, než vývojář vypne varování úplně. Proto se vývojáři mnohdy snaží potlačovat varování u kódu, který je správně – což je postup mající jiné nechtěné důsledky.

GCC při použití vhodných voleb vypíše varování, pokud je přesvědčeno, že některá proměnná může být použita před nastavením její hodnoty. Toto varování je založeno na analýze kompilátoru, který zkoumá možné průchody kódem; pokud najde cestu, kde není proměnná inicializována, uvidíte varování na „neinicializovanou proměnnou“. Problém je v tom, že kompilátor je ne vždy dostatečně chytrý při provádění svých analýz. Pěknou ukázkou je funkce uhid_hid_get_raw()drivers/hid/uhid.c:

size_t len;
/* ... */
return ret ? ret : len;

Při pohledu na okolní kód je člověku jasné, že pokud je ret nastaveno na nulu, tak byla hodnota len náležitě nastavena. Jenže kompilátor není schopen toto vydedukovat a varuje, že len může být použito v neinicializovaném stavu.

Zjevně se na toto varování dá reagovat úpravou deklarace, kde proměnnou rovnou inicializujeme:

size_t len = 0;

Toto je postup, od kterého jaderní vývojáři obvykle odrazují. Nepotřebná inicializace vede ke generování více kódu a (lehce) delšímu běhu. Navíc člověka rozčiluje, když si kompilátor vymýšlí a vy se tomu musíte přizpůsobovat; Skuteční jaderní hackeři něco takového netolerují. Proto bylo přidáno speciální makro:

/* <linux/compiler-gcc.h> */
#define uninitialized_var(x) x = x

V deklaracích se používá takto:

size_t uninitialized_var(len);

Toto makro má za následek potlačení varování, ale nevede ke generování žádného dodatečného kódu. Makro se stalo dosti oblíbeným; rychlý grep odhalí, že v repozitáři verze 3.7+ má 280 výskytů. Není se čemu divit: umožňuje vývojářům vypnout chybné varování a rovnou tento fakt dokumentovat.

uninitialized_var() má ale své vlastní problémy. Jedním je, že přesvědčením GCC, že proměnnou inicializujeme, jej také přesvědčujeme, že proměnnou používáme. Pokud tato proměnná není nikde jinde použita, kompilátor pak už nevypíše varování o „nepoužité proměnné“. Proto je pravděpodobné, že existuje spousta nadbytečných proměnných, jež nebyly odstraněny, protože nikdo nezaregistroval, že nejsou doopravdy používány. To trochu naštve, ale ještě by se to dalo přejít, kdyby ale šlo o nedostatek jediný.

Dalším problémem je ale to, že kompilátor měl možná původně pravdu. Během začleňovacího okna verze 3.7 byl zařazen patch přesouvající kód pracující s rozšířenými atributy z tmpfs do obecného kódu. Během toho si vývojář všiml, že by bylo možné odstranit jednu inicializaci proměnné, protože se zdálo, že získá svou hodnotu někde jinde. GCC nesouhlasilo a varovalo, takže když tento vývojář napsal druhý patch, tak rovnou varování potlačil pomocí uninitialized_var(). GCC ale tentokrát vědělo, o čem mluví; do kódu byl tudíž zavlečen bug, kdy za určitých okolností kfree() dostalo neinicializovanou proměnnou, což má jednoznačně dosti výbušné následky. Bug museli vystopovat jiní vývojáři; opravu provedl David Rientjes 17. října. A zrovna tehdy Hugh Dickins řekl, že jde o dobrou ukázku toho, jak se může používání uninitialized_var() pokazit.

A podobný problém by tam samozřejmě nemusel být od začátku. Kód mohl být už od svého počátku správě a stejně tak uninitialized_var() mohlo být použito správně. Jenže změny v budoucnu by pak mohly způsobit chybu, na kterou by kompilátor obvykle varoval, kdyby ho ovšem neumlčeli. Proto je každé použití uninitialized_var() pastí, do které se neznalý člověk snadno chytí.

To je ostatně proč Linus v říjnu varoval, že tuto věc, kterou nazval odporností, odstraní:

Je to postavené na hlavu. Máme to tu prakticky jen kvůli chybám v kompilátorech (*hloupé* chování gcc) a bylo by lepší, kdybychom použili explicitní (zbytečnou) inicializaci, která alespoň nepovede k náhodným pádům v případě chyby.

V reakci na to Ingo Molnar sestavil patch, který kompletně odstraňuje uninitialized_var(). Každé použití makra je nahrazeno příslušnou inicializací proměnné. K tomu je připojen komentář /* GCC */ označující důvod dané inicializace.

Patch byl přijat kladně a zdá se, že má cestu do jádra volnou. V říjnu Ingo řekl, že patch do linux-next nedá (aby předešel nesčetným konfliktům při slučování), ale nechá jej zařadit hned na konci okna verze 3.8. V době psaní tohoto textu se tak ještě nestalo, ale nic nenasvědčuje tomu, že by se tento záměr neměl uskutečnit. Proto je pravděpodobné, že v jádře 3.8 už makro uninitialized_var() nebude a vývojáři budou muset umlčnovat kompilátor postaru.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

14.1.2013 17:33 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Za zkušenosti má kompilátor vždy pravdu, když varuje, i když tvrdí trochu něco jiného, než co je skutečný problém. Použití return ret ? ret : len; ukazuje na nepříliš promyšlenou strukturu kódu, protože zbytečně porovnávám ret na konci funkce, když už někde dříve muselo být jasné a musel jsem otestovat, že není nulové (a tedy jsem měl funkci ukončit už tam), protože jinak by len bylo inicializováno.
14.1.2013 18:29 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
To není tak úplně jisté...

Jednak mám dojem, že dle C89 (s -pedantic) musíš mít deklarace proměnných na začátku scope. Ale nevim, podle jakýho standardu se kompiluje jádro.

No a jednak si umím představit i takovej kód, kde by to opravdu muselo být rozlišeno až na konci. Asi by to chtělo vidět ten konkrétní kód...
14.1.2013 20:16 Sten
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Jednak mám dojem, že dle C89 (s -pedantic) musíš mít deklarace proměnných na začátku scope. Ale nevim, podle jakýho standardu se kompiluje jádro.
To by nevadilo, to varování vyvolá až použití.
No a jednak si umím představit i takovej kód, kde by to opravdu muselo být rozlišeno až na konci. Asi by to chtělo vidět ten konkrétní kód...
Já si ho samozřejmě taky umí představit, to ale neznamená, že je strukturálně správně.
Goheeca avatar 14.1.2013 21:25 Goheeca | skóre: 7
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
static int uhid_hid_get_raw(struct hid_device *hid, unsigned char rnum,
			    __u8 *buf, size_t count, unsigned char rtype)
{
	struct uhid_device *uhid = hid->driver_data;
	__u8 report_type;
	struct uhid_event *ev;
	unsigned long flags;
	int ret;
	size_t uninitialized_var(len);
	struct uhid_feature_answer_req *req;

	if (!uhid->running)
		return -EIO;

	switch (rtype) {
	case HID_FEATURE_REPORT:
		report_type = UHID_FEATURE_REPORT;
		break;
	case HID_OUTPUT_REPORT:
		report_type = UHID_OUTPUT_REPORT;
		break;
	case HID_INPUT_REPORT:
		report_type = UHID_INPUT_REPORT;
		break;
	default:
		return -EINVAL;
	}

	ret = mutex_lock_interruptible(&uhid->report_lock);
	if (ret)
		return ret;

	ev = kzalloc(sizeof(*ev), GFP_KERNEL);
	if (!ev) {
		ret = -ENOMEM;
		goto unlock;
	}

	spin_lock_irqsave(&uhid->qlock, flags);
	ev->type = UHID_FEATURE;
	ev->u.feature.id = atomic_inc_return(&uhid->report_id);
	ev->u.feature.rnum = rnum;
	ev->u.feature.rtype = report_type;

	atomic_set(&uhid->report_done, 0);
	uhid_queue(uhid, ev);
	spin_unlock_irqrestore(&uhid->qlock, flags);

	ret = wait_event_interruptible_timeout(uhid->report_wait,
				atomic_read(&uhid->report_done), 5 * HZ);

	/*
	 * Make sure "uhid->running" is cleared on shutdown before
	 * "uhid->report_done" is set.
	 */
	smp_rmb();
	if (!ret || !uhid->running) {
		ret = -EIO;
	} else if (ret < 0) {
		ret = -ERESTARTSYS;
	} else {
		spin_lock_irqsave(&uhid->qlock, flags);
		req = &uhid->report_buf.u.feature_answer;

		if (req->err) {
			ret = -EIO;
		} else {
			ret = 0;
			len = min(count,
				min_t(size_t, req->size, UHID_DATA_MAX));
			memcpy(buf, req->data, len);
		}

		spin_unlock_irqrestore(&uhid->qlock, flags);
	}

	atomic_set(&uhid->report_done, 1);

unlock:
	mutex_unlock(&uhid->report_lock);
	return ret ? ret : len;
}
Stačilo by přiřadit len do ret v té else větvi.
15.1.2013 17:50 kralyk z abclinuxu | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
No to je teda prasečina... Nelíbí se mi na tom, že ret i celá ta funkce je int, kdežto len je size_t.
Goheeca avatar 16.1.2013 15:09 Goheeca | skóre: 7
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Jo to implicitní přetypování se mi taky nelíbí.
14.1.2013 17:40 j
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
A nebylo by lepsi opravit ten kompilator?
14.1.2013 19:00 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Jestli pod 'opravit' myslis upravit GCC tak, aby nehlasil to varovani tam, kde nemuze k problemu dojit, a hlasil tam, kde muze, tak to principielne neni mozne. At pouzijes sebelepsi algoritmus, tak vzdy jsou pripady, kdy nelze spolehlive ani potvrdit ani vyvratit chybu, a maximalne v takovych pripadech lze zvolit zda hlasit varovani (a riskovat false positive) nebo nehlasit (a riskovat false negative). Pritom ty priklady mohou byt treba prokazatelne korektni. Abych se nepoustel do konstrukci spojenych s vycislitelnosti, tak staci vzit v uvahu pripad, kdy chovani zavisi na nejakem vnejsim faktoru (napr. externi funkci), o niz kompilator nema zadne informace, ale programator ma.
14.1.2013 19:03 teoretik
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Opravit? U te analyzy inicializaci se v extremnich pripadech muze jednat o ekvivalent problemu zastaveni, tedy o neco algoritmicky neresitelneho. I kdyz mohl by to Honza Hubicka zadat jako semestralku studentum, treba mu to nekdo omylem vyresi... :)
14.1.2013 19:47 ::: | skóre: 14 | blog: e_lama
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
poslyste vy dva teoretici nademnou. Principielne resitelny to samozrejme je a s problemem zastaveni to nema nic spolecnyho.

Ale je pravda ze kvuli volani dalsich funkci nemusi mit kompilator vsechny potrebny informace a shanet je by zbytecne zpomalovalo preklad.
The enemy of my enemy is still my enemy.
14.1.2013 21:14 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Principielne resitelny to samozrejme je a s problemem zastaveni to nema nic spolecnyho.

Důkaz máte? :)

14.1.2013 22:34 teoretik
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Nejsem sam kdo si to mysli:

http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings <- "Unfortunately, detecting when the use of an uninitialized variable is equivalent, in the general case, to solving the halting problem."
Grunt avatar 14.1.2013 22:28 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Co třeba inicializace na nějakou předefinovanou hodnotu nečíselného typu (podobně jako je NaN) kdy při libovolné operaci s touto hodnotou vyhodí procesor debugovací přerušení nebo si udělá zářez na křemík nebo tak něco? Bylo by to o moc blbější?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Bluebear avatar 14.1.2013 23:46 Bluebear | skóre: 30 | blog: Bluebearův samožerblog | Praha
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Ale co dělat u integerů? :-)

Respektive, dalo by se přidat zvláštní flag "je-není inicializován". Bohužel myslím, že tohle tam dát, tak Linus vezme nunčaky a půjde po krvi toho, kdo ten patch do GCC poslal.

Ukazatele by samozřejmě šlo inicializovat na NULL, a osobně bych byl pro, ale spousta lidí by (právem) začala nadávat, že to je v drtivé většině případů zcela zbytečná instrukce a přístup do paměti.
To mi připomíná, jak jsem si pořídil květináč, že v něm budu mít květinu. Opravdu tam byla, ale potom být přestala...
Grunt avatar 15.1.2013 09:21 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Ale co dělat u integerů?
To by se asi muselo implementovat na procesoru, kdy libovolná aritmetická operace s nějakým specifickým číslem (nebo číslem s flagem) by způsobila vyhození z běžného běhu.
Ukazatele by samozřejmě šlo inicializovat na NULL, a osobně bych byl pro, ale spousta lidí by (právem) začala nadávat, že to je v drtivé většině případů zcela zbytečná instrukce a přístup do paměti.
Tak třeba #ifdef DEBUG. Furt lepší kfree(NULL) než kfree(rand()).
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
15.1.2013 08:10 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Pokud někdo potřebuje něco takového, tak nepoužije C, ale Adu. C má mnohem více záludnějších problémů ,jako ke třeba přetečení znaménkového integeru. Ostatně těšte se na GCC 4.8, které jde s optimalizacemi ještě více na dřeň specifikace, kdy například takovéto přiřazení do iterátoru povede k zacyklení programu.
Grunt avatar 15.1.2013 09:17 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Pokud někdo potřebuje něco takového, tak nepoužije C, ale Adu.
Takže už jen stačí přepsat jádro z Céčka do Ady…
jako ke třeba přetečení znaménkového integeru
V tom problém nevidím. Když přeteče, tak se začne počítat znova od spodní hranice rozsahu, ne?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Voty avatar 15.1.2013 12:07 Voty | skóre: 12 | blog: gemini
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
jako ke třeba přetečení znaménkového integeru
V tom problém nevidím. Když přeteče, tak se začne počítat znova od spodní hranice rozsahu, ne?
Dle normy je to nedefinovaná operace a tudíž se může stát cokoliv. Například v kódu:

int a, b;

...

if(a > 0 && b > 0)
{
    int c = a + b;
    
    if(c < 0)
    {
        printf("Overflow");
    }
}

může překladač usoudit, že při sčítání dvou kladných čísel nemůže nastat "legální" situace, kdy výsledek součtu bude záporný a Overflow se nikdy nevypíše.
Jednu rozbil a tu druhou ztratil.
Grunt avatar 15.1.2013 12:36 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
  1. Furt nevidím problém
  2. Tohle
    if(c < 0)
        {
            printf("Overflow");
        }
    mi moc validní nepřijde. Není k detekci přetečení určen overflow flag v SR?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
Voty avatar 15.1.2013 15:47 Voty | skóre: 12 | blog: gemini
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Byla to jen ukázka, co se může stát (přišlo mi to lepší než příklad s auty :)

Každopádně jde o to, že u znaménkových integerů v jazyce C obecně neplatí (nelze se spolehnout) na to, že se začne počítat od spodní hranice rozsahu. A vyrobit podobnou chybu může být poměrně snadné, v příkladu je naznačen jeden možný (a zcela zřejmý) postup.

Norma C poměrně jasně říká, že pokud dojde k přetečení integeru, může se dále dít prakticky cokoliv a další chování programu je _zcela_ nedefinované. Mimojiné je tak překladači dovoleno jakékoliv testy na zjištění, že došlo k přetečení ignorovat a v rámci optimalizace je úplně vyhodit. Nehledě na to, že svět není jen x86 a některé arch overflow flag ani nemají.
Jednu rozbil a tu druhou ztratil.
15.1.2013 22:38 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Jaderné noviny – 20. 12. 2012: Umlčování GCC ne vždy přínosné
Doporučuji nečíst vlákno, proč bash vrací na $((2**63)) divný výstup. Mohl byste mít špatné spaní.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.