Dotaz: Ukazatele v C

[Jiří Daněk]

Dobrý den. Chtěl bych se zeptat, proč tento kód provede bez chyb:

void main(void)
{
int *p;
p = (int *) malloc(sizeof(int *) * 5);
p[2]=10;
p[50]=11;
printf("%d", p[50]);
free(p);
}
A jak by se, prosím vás, dalo toto zapsat správně? Díky.

Odpovědi

[Kyosuke]

Provede se "správně" v tom smyslu, že to náhodou funguje. Jestli to chápu správně, příslušné systémové volání kernelu přiděluje procesu paměť de facto po násobcích stránek - částečně stránku přidělit nemůže. Ten pointer se trefí do části přidělené systémovým voláním, ale nikoli do oblasti zaregistrované jako přidělené pomocí standardní funkce malloc. Takže kernel OS si ničeho nevšimne a malloc/free mechanismus o těch datech přehled taky nemá.

A že to náhodou funguje nemusí znamenat, že to bude fungovat vždy a všude.

[Jirka]

1. Nejsem si jistý, zda to nepatří do jiného fóra než do Linuxu.

2. Otázka je nějak divně formulována. Nejdřív se ptáte, "proč tento kód provede bez chyb", pak "jak by se toto dalo zapsat spravně". Moc tomu nerozumím. Otázka o správnosti úzce souvisí i s tím, co to má dělat. To taky není jasné.

3. Pointer p ukazuje na int, ale alokujete pamět na 5 ukazatelů na int, nikoliv na 5 integerů.

4. Ochrana přístupu do oblasti mimo alokovanou paměť je asi věcí systému. Takže patrně záleží i na tom, pod čím to pouštíte.

Jirka

[trekker.dk]

3. Pointer p ukazuje na int, ale alokujete pamět na 5 ukazatelů na int, nikoliv na 5 integerů.

Na většině systémů jsou oba typy 32bitové, takže žádný problém.

[finn]

Tím hůř. Hledat chybu, která se projevuje jen při konjunkci Jupiteru s Marsem, je nezáviděníhodný úkol.

[Michal Kubeček]

To nebylo příliš povedené ani jako vtip. Pokud jste to náhodou myslel vážně, mohu vám poradit jediné: neprogramujte, a neposlechnete-li mne, aspoň své výtvory nezveřejňujte.

[VícNežNic]

Jsou jazyky kde by mu to nebylo dovoleno (nebo spíš, kde by něco takového nemělo smysl dělat), tak ohledně programování není ještě nic ztraceno

[Michal Kubeček]

Tady jde spíš o přístup, s takovým by ho nezachránil ani Karel…

[trekker.dk]

Na většině systémů jsou oba typy 32bitové, takže žádný problém při překladu a spuštění na platformě x86 nenastane

Pokud si myslíte, že tím jsem chtěl tvrdit, že ten zápis je programátorsky v pořádku, tak nechtěl

Suma sumárum k té vaší radě - trhněte si nohou !

[Michal Kubeček]

Nohou si netrhnu. Už to tu padlo jednou, ale asi je třeba to zopakovat: program, který většinou funguje, je daleko nebezpečnější, než program, který nefunguje skoro nikdy.

[VícNežNic]

Ale zase je aspoň nějaká šance že občas udělá co má

(já jenom tak rejpu, původně jsem pouze naznačoval, že ačkoliv to samozřejmě chyba je, tak na řešený problém to nejspíše vliv nemá)

[trekker.dk]

Otázka zněla, proč se daný kód provede bez chyb. Odpověď: protože na dnešních x86 sizeof(int) == sizeof(int*). Za tímhle tvrzení si stojím. Tečka.

#include <stdio.h>

int main (void) {
 printf ("%i, %i\n", sizeof(int), sizeof(int*));
 return 0;
 }

#gcc -o sizeof -Wall -pedantic sizeof.c
#./sizeof
4, 4
#

Nikdy jsem netvrdil, že ten zápis v otázce je dobře nebo dokonce že by se to tak mělo dělat. Nikdy jsem netvrdil, že přístup "na x86 to bude fungovat, tak to tak nechám" je správný. Proto mi ani nemusíte opakovat, že

program, který většinou funguje, je daleko nebezpečnější, než program, který nefunguje skoro nikdy.

Opravdu nemusíte. Vím to sám.

[Viliam Púčik]

Takto sa ti program sice skompiluje, ale urcite nepracuje spravne....

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
	int *p;
	p = (int *) malloc(sizeof(int *) * 5);
	p[2]=10;	
	p[50]=11;
	printf("%d", p[50]);
	free(p);
	
	return 0;
}

V prvom rade su dost podozrive nasledujuce prikazy:

p = (int *) malloc(sizeof(int *) * 5);
p[2]=10;

Vytvoril si si totiz volnu pamat velkosti (5*smernik na int) a nasledne zapisujes do tohto pola ako by to bolo pole intov. Pravdepodobne to malo vyzarat takto:

p = (int *) malloc( sizeof(int) * 5 );

Takisto tu je problem s tym, ze zapisujes na miesto, ktore ti takpovediac nepatri (p[50]=11;)...
Normalny program by vyzeral asi takto:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
	int *p;
	p = (int *) malloc( sizeof(int) * 51 );
	p[2]=10;	
	p[50]=11;
	printf("%d", p[50]);
	free(p);
	
	return 0;
}

[Viliam Púčik]

Ako pozeram, uz to tu niekto predo mnou napisal. Asi som si zabudol reloadnut stranku...

[VícNežNic]

No, jenže vzhledem k tomu, že ukazatel na int a int mají třeba u mě shodnou velikost čtyř bajtů, tak to na funkčnost programu přímý vliv nějak extra asi mít nebude

[Viliam Púčik]

... tak to na funkčnost programu přímý vliv nějak extra asi mít nebude

Skompiluj to pod inym kompilatorom (GCC/...) alebo pod inym systemom (Linux/Wind32/Win16/...) alebo pod inou platformou a uvidis aky to bude mat extra vplyv

[VícNežNic]

No samozřejmě Ale u tazatele čekám podmínky dost podobné. A i kdyby, tak to bude třeba dvakrát víc nebo půlka, to ještě není tak hrozné

[Michal Kubeček]

Bylo by to celkem vtipné, kdyby stejně neuvažovala spousta programátorů a kdyby podle této logiky nepsali své aplikace…

[VícNežNic]

Zase si představte svět, kde by se všechno na první pokus zkompilovalo a i běželo bez chyb, kdo by tam chtěl žít?

[Michal Kubeček]

Lidé, kteří mají u producentů distribucí na starosti balíčkování? :-)

[podlesh]

Zásada č.I: zapni všechny warningy (-Wall)

Zásada č.II: vždy používej nějaký malloc debugger.

Jedním z nejjednodušších je electric fence, stačí jen přilinkovat k binárce -lefence . Nedělá nic jiného než že zajistí, že takto špatně napsaný program spolehlivě chcípne na SIGSEGV (jak se sluší a patří).

[Josef Kufner]

Tohle je ideální pro výlet do krajin obývaných démony, draky a coredumpy...

Tím že něco napíšeš do paměti, kterou ti sice systém věnoval, ale nemáš zaručeno co tam je nebo bude, si fakt koleduješ o opravdu divné chování programu a okamžitý segfault je to nejlepší co tě v tomhle případě může potkat. To že to náhodou funuje je asi ta nejhorší varianta.

Jakmile napíšeš něco většího, tak si tímhle přepíšeš data, která můžou patřit čemukoliv a například pokud si přepíšeš pár byte za alokovanou pamětí tak se jí obvykle nepovede uvolnit, protože malloc tam má něco uloženého... nebo si přepíšeš nějakou drobnost a třeba GTK si pak při odebrání posledního widgetu z hboxu bude hrát na ospalou a bude kašlat na další data přicházející z unixového socketu, který se inicializuje úplně někde jinde a vlastně s ním gtk ani nic nedělá...

[Jiří Daněk]

Mě spíš trápí rápí ten zápis do nalokované paměti (i[55] =5;). To by mi přece nemělo být dovoleno. A měl bych ještě jeden kousek podivného malloc kódu načítajícího soubor do pole:

char **pole;
scena = fopen( "./config/scena.txt" , "rt");
pole = (char **)malloc(sizeof(char*));
char buffer[512];
while(fscanf(scena, "%s",&buffer) != EOF){
pole[i] = (char *)malloc(sizeof(char) * strlen(buffer));
strcpy(pole[i], buffer);
i++;
}

Já si myslím, že to nemůže fungovat, ale funguje, a dokonce spolehlivě (hru obsahující toto jsem spustil tak stokrát).

[VícNežNic]

To je v nějakým veřejně dostupným OSS projektu? Abych se tomu zdaleka vyhnul

[Jiří Daněk]

Ne. Je to moje dílko. Tedy už se to tam nevyskytuje .

[Josef Kufner]

Fungovat to za nekterych okolnosti bohuzel bude. Jde o to, ze se pamet alokuje po blocich a pokud je mez pole prekrocena jen o kousek, tak to projde. Ovsem je tu jiny problem, o kterem jsem uz psal: nikdo nevi co tam je a co se tim prepise. Muze to byt nevyuzite misto a je to v pohode, ale taky to muze byt kus kodu nebo jina data programu a pak je to horsi nez vylet do rise divu...

[VícNežNic]

Tohle mi funguje spolehlivě

void main (void) {
        printf ("%d\n", sbrk (0));
        int *p = (int *) malloc (sizeof (int) * 10);
        printf ("%d\n", sbrk (0));
        int *i = (int *) sbrk (0);
        printf ("Tohle je jeste moje\n");
        *(i - 1) = 100;
        printf ("Tohle uz ne a nastane konec \n");
        *i = 100;
}

[trekker.dk]

Kyosuke to popisuje hned v prvním příspěvku. Paměť je přidělována po stránkách, takže ten program sice píše mimo alokované pole, ale stále do "své" stránky, takže žádný segfault.

Problém nastane, když se při nějaké další alokaci zabere zbytek té stránky něčím jiným, a volání typu i[55] = 5 to přepíše - pak se program bude chovat zcela nevypočitatelně.