Array størrelse via pointer

[zotbar1234]

Flere ganger på dette forumet har folk fått problemer fordi de har allokert et array slik:

int myints[100];
int mysecondint;
myints[100] = 1000;

og funnet ut at dette fører til at mysecondint blir satt til 1000. Dette er også hele grunnøaget for stackoverflow angrep som baserer seg utelukkende på slike stackallokerte arrays uten bounds checking i C og C++ fører til at data vil overskrive påfølgende minneområde.

 

Jeg sa aldri at det ikke var viktig å ha et bevisst forhold til array-grensene og slike typiske off-by-one feil.

 

Poenget er at semantikken til sizeof-operatoren er helt uavhengig av den underliggende lagringsmodellen og det hjelper ikke på forståelsen å hevde ting som er direkte feilaktige, selv gitt en typisk implementasjon.

 

Det kan være at C++ standarden sier noe annet (...)

 

På hvilket punkt? I kodeeksempelet over sier C++-standarden *ingenting* om oppførselen til programmet (derav viktigheten av å ikke aksessere objektet utenfor grensene).

[bjaanes]

Artig tråd. Har akkurat satt igang med c++ igjen og fant denne tråden og ble gira på å finne ut litt mer selv (slik at jeg nå forstår hele tråden ).

 

Slik jeg ser det har zotbar1234 teoretisk rett, mens GeirGrusom har praktisk rett. Siden dette er et hjelpeforum så vil vel den praktiske forklaringen være den mest "rette".

 

Optimalt burde vel kanskje zotbar holdt seg til å skyte inn at "teoretisk sett er ting bla bla og kan være teoretisk bla bla dersom din teoretiske usannsynlig maskin sånn og sånn" i stedet for å hardnakka påstå at Geri tar FEEEEIL og at hans svar er ubrukelig (noe det ikke er, såvidt jeg kan skjønne )

 

Tenkte jeg kunne dra ut en liten quote fra boka jeg leser nå:

"Every int is of the same size; that is, the compiler sets aside the same fixed

amount of memory for each int. On a typical desktop computer, that amount is 4

bytes (32 bits)."

 

Side 78, paragraf 2 - Programming - Principles and Practice Using C++

 

 

Edit:

Men hey, kan være jeg driter meg skikkelig ut nå

Endret 3. april 2010 av bjaanes

[zotbar1234]

Slik jeg ser det har zotbar1234 teoretisk rett, mens GeirGrusom har praktisk rett.

 

Nei, h*n har ikke det. Derav innvendingen.

 

Optimalt burde vel kanskje zotbar holdt seg til å skyte inn at "teoretisk sett er ting bla bla og kan være teoretisk bla bla dersom din teoretiske usannsynlig maskin sånn og sånn" i stedet for å hardnakka påstå at Geri tar FEEEEIL og at hans svar er ubrukelig (noe det ikke er, såvidt jeg kan skjønne )

 

GeirGrusom tar feil. Punktum. Jeg har allerede skissert hvor og hvordan.

[CoolBeer]

Vil nok si meg enig i at(uten å ha satt meg 100% inn i standarden) det er en ulempe å faktisk definere størrelse på en int i standarden til et språk, da optimal int størrelse er noe forskjellig fra platform til platform. Og ja, det finnes platformer idag som ikke er 32/64bit, jeg driver foreksempel med AVR microkontrollere, som for det meste kun har 8bit registre.

[bjaanes]

Ja, det var vel litt av poenget her? På noen kanskje heller noe sære plattformer/kompilatorer vil størrelsen variere. Men det er mer detaljer enn noe særlig annet? Størrelsen er ikke definert i standarden, men som oftest vil den være 32-bit. For de fleste vil det være mer enn godt nok. Dermed vil en kommentar om at det ikke alltid er sånn være nok. IMO.

[CoolBeer]

Standarden sier vel noe som at den skal være minst like stor eller større enn den foregående størrelsen. Eksempel kan være at en short int skal være mindre eller lik en int som igjen skal være større/lik short men mindre/lik en long int. Rekka går vel char->short->int->long->long long hvis jeg ikke tar helt feil, litt avhengig av standard, da long long ikke er inne i c++ standarden enda.

 

Er ganske sikker på at GCC opererer med 64bit int på linux forresten(under 64bit os selvfølgelig) og har selv hatt problemer med programvare som antar at innebygde typer er en viss størrelse, så det er egentlig greit å være obs på det ettersom det kan bli problemer ut av det.

Nå er det heldigvis sjelden man kommer i slike situasjoner, men helt hypotetisk, om en lager et program på en platform som har 64bit int, kompilerer dette på en 32bit platform som har 32bit int, og dette programmet faktisk trenger tall som er større enn 32bit, kan dette føre til problemer. Kompilator vil forhåpentlighvis rope høyt ut om dette, men er koden skrevet litt fancy, er det ikke sikkert kompilatoren gjør det.

 

Selv har jeg begynt å bruke boost typene for å holde meg mest mulig platform-uavhengig, ettersom jeg kompilerer samme kode på både GCC og VC++08, og da vet jeg iallefall hvilke størrelser jeg håndterer.

 

-

Kolbjørn

[TheMaister]

int i GCC på Linux x86_64 er 32-bit, long er 64-bit.

Forøvring synes jeg det er god praksis å benytte seg av (u)int{8,16,32,64}_t i <stdint.h>, når man eksplisitt krever et visst antall bit i C.

Endret 5. april 2010 av TheMaister