Thanks guys for t input.

Nå n1, jeg tænkte på samme måde. Tager det et skridt videre, da j blev afsat 15 bytes, selvom jeg input en buffer på sige 20 (dybest> 15), programmet ikke standse.

Nu antages tht k peger på nogle placering på / omkring rummet afsat til j, hvorfor denne betingelse ikke give anledning til en overflow og derefter fremkalde en SEGV?

Shouldn't SEGV opstå, når mit program adgangsveje nogen hukommelse uden for den tildelte plads? (endsige gyldig / ugyldig addessses)

Også, bemærkede jeg tht forud for en sprintf på 'k', dens værdi var engang, at i Stdout, og én gang af strengen i sprintf. Så måske disse behandles som gyldige adresser og inden programmet grænserne?

BTW, jeg kom op med ovennævnte scenario accidently, når man eksperimenterer noget. Også, jeg ved med sikkerhed, hvad jeg gør, er ulovligt, men perplexes mig, når det virker!

Det er en gennemførelse detaljer, hvordan strenge dette er nogle arkitekturer kan lige tilkalde op til den virtuelle hukommelse og føje det til din arbejdsdag sæt, især hvis OS mener du bare udvide stakken.

Også forskellige arkitekturer er strengere end andre med hensyn til (a) skriftligt over kode områder (b) udrettet forkert adgang.

Har du forsøgt at udskrive indholdet af 'j', når den eksisterer? Siden indførelsen af 'j' er, hvad der forårsager SEGV at stoppe så jeg vil gætte på dens indhold er at påvirke resultatet.

Alle er så fokuserede på 'k', har jeg endnu ikke se nogen nævne »i«. Den sprintf skal traverse uanset indholdet »i« er at pege på og udleder, at 'k'. Jeg formoder, at 'j' og 'jeg' har mere en relation end 'j' og 'k'.

Hvis jeg var nødt til at tage et gæt, 'j' (når den findes) har, på et tidspunkt, en null terminatorsekvenser ( '\ 0') i den, og »i« er (på et tidspunkt før SEGV) kører ind i Indholdet af "J". Dette har selvfølgelig begrænser mængden af "affald" kan du både læse og holde fast i unreferenced 'k' og dermed mindsker muligheden for at SEGV.

Tag 'j' ud af billedet og sprintf naturligvis løber ind i et område med hukommelse bør det ikke. Mit gæt, mens sprintf er kører »i« enten du overflow dælen ud af "k", fordi der ikke er nogen null terminatorsekvenser i hukommelsen i temmelig lang tid, eller der ikke er nogen null terminatorsekvenser før sprintf bliver i teksten segment og OS ikke kan lide det overtrædelse af de data segment.

Jeg vil teste min teori, men AIX støbekerner uanset tilstedeværelsen af "J".

kunne være, men når jeg udskrives indholdet af j, det var "" (naturligvis, da det er en dummy).
Men måske kunne der være nogle skrald i de 15 bytes tildelt.
Ligesom u nævnt, må vi dump kerne begge gange.

Også, ligesom porter nævnt er det op til OS når / hvor meget det skal være præcise.

En SEGV per definition betyde, du forsøger at skrive til et segment uden hukommelse tildelt dig. I det første tilfælde, du havde ingen oplagring tildeles kun henvisninger, så den første skrive gav dig SEGV. Den anden er sværere at opdage en fejl. Så længe du er ved at skrive til nogen hukommelse er afsat til dig, vil du ikke få et SEGV. Din pointers kun ske til at pege på tildeles hukommelse, i dette tilfælde din j [] karakter array. Skriv nok ting der, og du får en SEGV der også, når du falder af i slutningen af din tildeles hukommelse. Den compiler & run tid libs har ingen idé, hvis du ønsker at pege på tildeles hukommelse, eller hvor i, at de afsatte hukommelse, du vil gerne med Deres pointers. Så længe du peger på tildeles hukommelse, runtime, vil ikke udstede en SEGV (Du er ikke skriftligt uden for tildelt hukommelse)

Typisk stakke er forlænget med segment krænkelser, i stedet for at afsætte en stor stak til en proces, det sætter vagt sider under det, og når du falde over dem, det vokser stakken.

De ville sige "selvfølgelig" men "selvfølgelig" alle de andre henvisninger bør sættes til NULL også. Skriv til NULL bør give anledning til SEGV .... Men hvis det er "" så det er en del af, hvorfor eksistensen af 'j' er at stoppe dig fra SEGV. Fordi mens sprintf er gennemkører strengen 'i' til at dumpe sit indhold i 'k', straks det rammer de NULL terminator og begrænser skaderne. Helt muligvis den "skade" gjort ligger helt inden for den tildelte stakken og aldrig SEGVs. Uanset hvad, er du clobbering ting, du bør ikke.

Desuden er jeg ikke sikker på, at en SEGV (pr. definition) er altid skyldes skriver. Der er en tekst og data segment, og jeg vil formode, at et forsøg på at læse teksten segmentet også kan forårsage en SEGV i nogle operativsystemer.