Hva betyr det å gjøre en “ nullkontroll ” i C eller C ++?

I C og C ++ er pekere i utgangspunktet usikre, det vil si når du refererer en peker, det er ditt eget ansvar å sørge for at det peker et sted gyldig, dette er en del av hva «manuell minnestyring» handler om (i motsetning til de automatiske minnestyringsordningene som er implementert på språk som Java , PHP eller .NET-kjøretiden, som ikke lar deg lage ugyldige referanser uten betydelig innsats).

En vanlig løsning som fanger mange feil er å sette alle pekere som ikke peker på noe som NULL (eller, i riktig C ++, 0), og sjekker om det før du får tilgang til pekeren. Spesielt er det vanlig praksis å initialisere alle pekere til NULL (med mindre du allerede har noe å peke dem på når du erklærer dem), og sette dem til NULL når du delete eller free() dem (med mindre de går utenfor omfanget umiddelbart etter det). Eksempel (i C, men også gyldig C ++):

void fill_foo(int* foo) { *foo = 23; // this will crash and burn if foo is NULL } 

En bedre versjon:

void fill_foo(int* foo) { if (!foo) { // this is the NULL check printf("This is wrong\n"); return; } *foo = 23; } 

Uten nullkontrollen, vil det å gi en NULL-peker inn i denne funksjonen føre til segfault, og det er ingenting du kan gjøre – OS vil bare drepe prosessen din og kanskje kjernedumpe eller dukke opp en krasjrapportdialog. Med nullkontrollen på plass, kan du utføre riktig feilhåndtering og gjenopprette elegant – korrigere problemet selv, avbryte den gjeldende operasjonen, skrive en loggoppføring, varsle brukeren, hva som helst som er passende.

Kommentarer

• @MrLister hva mener du, null sjekker fungerer ikke ‘ i C ++? Du må bare initialisere pekeren til null når du erklærer den.
• Det jeg mener er at du må huske å sette pekeren til NULL, ellers vant den ‘ t fungerer. Og hvis du husker, med andre ord hvis du vet at pekeren er NULL, vil du ikke ‘ ikke ha et behov for å ringe fill_foo uansett. fill_foo sjekker om pekeren har en verdi, ikke om pekeren har en gyldig verdi. I C ++ er det ikke garantert at noen peker har en gyldig verdi.
• En påstand () vil være en bedre løsning her. Det er ‘ ikke noe poeng å prøve å » være trygg «. Hvis NULL ble sendt inn, er det ‘ åpenbart feil, så hvorfor ikke bare krasje eksplisitt for å gjøre programmereren fullstendig oppmerksom? (Og i produksjon spiller det ingen rolle ‘ fordi du ‘ har bevist at ingen vil kalle fill_foo () med NULL, ikke sant? Det er ‘ ikke så vanskelig.)
• Ikke glem ‘ å nevne at en enda bedre versjon av denne funksjonen skal bruke referanser i stedet for pekere, noe som gjør NULL-sjekken foreldet.
• Dette handler ikke manuell minneadministrasjon, og et administrert program vil også sprenge, ( eller hev et unntak i det minste, akkurat som et eget program vil gjøre på de fleste språk,) hvis du prøver å referere til en nullreferanse.

Nullpekerverdien representerer et veldefinert «ingensteds»; det er en ugyldig pekerverdi som garantert vil sammenligne ulik med noen annen pekerverdi. Forsøk på å referere en nullpeker resulterer i udefinert oppførsel, og vil vanligvis føre til en kjøretidsfeil, så du vil forsikre deg om at en peker ikke er NULL før du prøver å gjenskille den. Et antall C- og C ++ – biblioteksfunksjoner vil returnere en nullpeker for å indikere en feiltilstand. For eksempel vil biblioteksfunksjonen malloc returnere en nullpekerverdi hvis den ikke kan tildele antall byte som er forespurt, og forsøk på å få tilgang til minne gjennom den pekeren vil (vanligvis) føre til til en kjøretidsfeil:

int *p = malloc(sizeof *p * N); p[0] = ...; // this will (usually) blow up if malloc returned NULL 

Så vi må sørge for at malloc samtalen lykkes ved å sjekke verdien på p mot NULL:

int *p = malloc(sizeof *p * N); if (p != NULL) // or just if (p) p[0] = ...; 

Nå, heng på sokkene dine et øyeblikk, dette kommer til å få en litt humpete.

Det er en nullpeker verdi og en nullpeker konstant , og de to er ikke nødvendigvis de samme. Nullpekeren verdi er hvilken verdi den underliggende arkitekturen bruker for å representere «ingensteds». Denne verdien kan være 0x00000000, eller 0xFFFFFFFF, eller 0xDEADBEEF, eller noe helt annet. Ikke anta at nullpekeren verdi alltid er 0.

Nullpekeren konstant , OTOH, er alltid et integrert uttrykk med 0 verdier. Når det gjelder kildekoden , representerer 0 (eller ethvert integrert uttrykk som evalueres til 0) en nullpeker. Både C og C ++ definerer NULL-makroen som nullpekerkonstant. Når koden din er kompilert, vil nullpekeren konstant erstattes med riktig nullpeker verdi i den genererte maskinkoden.

Vær også oppmerksom på at NULL bare er en av mange mulige ugyldige pekerverdier; hvis du erklærer en automatisk pekervariabel uten å eksplisitt initialisere den, for eksempel

int *p; 

, er verdien som først ble lagret i variabelen ubestemt , og tilsvarer kanskje ikke en gyldig eller tilgjengelig minneadresse. Dessverre er det ingen (bærbar) måte å fortelle om en ikke-NULL-pekerverdi er gyldig eller ikke før du prøver å bruke den. Så hvis du har å gjøre med pekere, er det vanligvis en god ide å eksplisitt initialisere dem til NULL når du erklærer dem, og å sette dem til NULL når de ikke aktivt peker på noe.

Merk at dette er mer et problem i C enn C ++; idiomatisk C ++ burde ikke bruke pekere så mye.

Det er et par metoder, alle gjør egentlig det samme ting.

 int *foo = NULL; //sometimes set to 0x00 or 0 or 0L instead of NULL 

nullkontroll (sjekk om pekeren er null), versjon A

 if( foo == NULL) 

nullkontroll, versjon B

 if( !foo ) //since NULL is defined as 0, !foo will return a value from a null pointer 

nullkontroll, versjon C

 if( foo == 0 ) 

Av de tre foretrekker jeg å bruke den første sjekken da den eksplisitt forteller fremtidige utviklere hva du prøvde å se etter OG det gjør det klart at du forventet at foo skulle være en peker.

Du trenger ikke. Den eneste grunnen til å bruke en peker i C ++ er fordi du eksplisitt vil ha tilstedeværelsen av nullpekere; ellers kan du ta en referanse, som både er semantisk enklere å bruke og garanterer ikke-null.

Kommentarer

• @James: ‘ ny ‘ i kjernemodus?
• @James: En implementering av C ++ som representerer mulighetene som et betydelig flertall av C ++ kodere liker. Det inkluderer alle C ++ 03 språkfunksjoner (unntatt export) og alle C ++ 03-biblioteksfunksjoner og TR1 og en god del av C ++ 11.
• Jeg ønsker at folk ikke ville ‘ ikke si at » referanser garanterer ikke-null. » De don ‘ t. Det er like enkelt å generere en nullreferanse som en nullpeker, og de forplanter seg på samme måte.
• @ Stargazer: Spørsmålet er 100% overflødig når du bare bruker verktøyene slik språkdesignerne og gode praksis foreslår at du burde.
• @DeadMG, det betyr ikke ‘ om det er overflødig. Du svarte ikke ‘ t svaret på spørsmålet . Jeg ‘ Jeg sier det igjen: -1.

Hvis du ikke sjekker NULL-verdien, spesielt hvis det er en peker til en struktur, kan du kanskje møte et sikkerhetsproblem – NULL-pekereferanse. NULL-pekereferanse kan føre til noen andre alvorlige sikkerhetsproblemer som bufferoverløp, løpstilstand … som kan tillate at angriper tar kontroll over datamaskinen din.

Mange programvareleverandører som Microsoft, Oracle, Adobe, Apple … slipper programvareoppdatering for å løse disse sikkerhetsproblemene. Jeg tror du burde sjekk NULL-verdien til hver peker 🙂