Bedankt jongens voor t-ingang.

N1 Nou, ik zat te denken over gelijksoortige lijnen. Rekening zij een stap verder, omdat J werd toegewezen 15 bytes, zelfs als ik het invoeren van een buffer van zeg 20 (in principe> 15), het programma niet stoppen.

Nu de veronderstelling THT k wijst op enkele locatie in / rond de toegewezen ruimte voor j, waarom is de bovenstaande voorwaarde niet leiden tot een overflow veroorzaken en vervolgens een SEGV?

Shouldnt SEGV optreden wanneer mijn programma toegangen enige geheugen buiten haar toegewezen ruimte? (laat staan geldige / ongeldige addessses)

Ook heb ik gemerkt THT voorafgaand aan een sprintf op 'k', de waarde ervan was ooit dat van stdout, en een keer van de string in sprintf. Dus misschien deze worden behandeld als geldige adressen en binnen de grenzen programma?

BTW, ik kwam met het bovenstaande scenario per ongeluk toen experimenteren iets. Ook weet ik zeker wat ik doe, is onwettig, maar perplexes me als het werkt!

Het is een implementatie detail hoe streng is, sommige architecturen misschien net roepen tot het virtueel geheugen en toevoegen aan uw werkgroep ingesteld, met name als het besturingssysteem denkt dat je gewoon een verlenging van de stack.

Ook verschillende architecturen zijn strenger dan anderen met betrekking tot (a) schriftelijk over code gebieden (b) verkeerd toegang.

Heeft u geprobeerd het afdrukken van de inhoud van de 'j' wanneer hij bestaat? Sinds de invoering van de 'j' is wat de oorzaak is van het SEGV te stoppen dan zou ik denk dat de inhoud ervan is van invloed op het resultaat.

Iedereen is zo gefocust op 'k', heb ik nog te zien wie vermelding 'i'. De sprintf traverse moet ongeacht de inhoud 'i' wijst naar uitstoten en dat 'k'. Ik vermoed dat 'j' en 'i' hebben meer dan een relatie 'j' en 'k'.

Als ik moest een gok, 'j' (indien aanwezig) heeft, op een bepaald punt, een null-terminator ( '\ 0') binnen, en 'i' is (op enig moment vóór de SEGV) loopt in de inhoud van de 'j'. Dit, natuurlijk, beperkt het bedrag van "afval" kan u zowel lezen en stok in de unreferenced 'k' en vermindert dus de potentie om SEGV.

Neem de 'j' uit het beeld en de sprintf uiteraard loopt in een gebied van het geheugen moet het niet. Mijn gok, terwijl de sprintf is traversing 'i' of je overflow the heck uit 'k' omdat er geen null-terminator in het geheugen al geruime tijd of is er geen null-terminator voor de sprintf krijgt in de tekst en het segment van de OS niet zoals het schenden van de gegevens segment.

Ik test mijn theorie, maar AIX gietkernen ongeacht de aanwezigheid van 'j'.

kunnen worden, maar toen ik uitgeprint inhoud van J, het was "" (uiteraard, want het is een dummy).
Maar misschien kan er wat afval in de 15 bytes toegewezen.
Zoals u zei, moet dumpen kern zowel tijden.

Ook, net als portier vermeld is het de taak van het OS wanneer / hoeveel moet worden streng.

Een SEGV per definitie betekenen dat u probeert te schrijven aan een segment buiten geheugen toegewezen aan jou. In het eerste geval, je had geen opslag toegewezen, alleen aanwijzingen, zodat de eerste schrijf je gaf de SEGV. De tweede is moeilijker op te sporen een fout. Zolang u zich schriftelijk aan ENIGE geheugen toegewezen aan u, u zult niet krijgen SEGV. Uw suggesties alleen gebeuren te wijzen op toegewezen geheugen, in dit geval uw j [] karakter array. Schrijf genoeg spul daar, en je krijgt een SEGV er ook, wanneer je valt uit het einde van uw toegewezen geheugen. De compiler en runtime bibliotheken hebben geen idee wanneer u wilt wijzen op toegewezen geheugen, of wanneer in die toegewezen geheugen u wil, met uw suggesties. Zolang je bereid bent te wijzen op toegewezen geheugen, de runtime, zal pas een SEGV (U bent niet schriftelijk buiten toegewezen geheugen)

Typisch stapels worden uitgebreid overtredingen per segment, in plaats van de toewijzing van een enorme stapel om een proces, zet het bewaken pagina's eronder en als je over die reis groeit de stapel.

Je zou zeggen "natuurlijk" maar dan "natuurlijk" alle andere aanwijzingen moeten worden vastgesteld om ook NULL. Schrijf NULL moeten veroorzaken SEGV .... Echter, als het is "" dan is dat deel van de reden waarom het bestaan van een 'J' is het stoppen van je van SEGV. Want terwijl sprintf is het doorkruisen van de string 'i' om de inhoud te dumpen in 'k', raakt hij onmiddellijk de NULL terminator en beperkt de aangerichte schade. Misschien wel de "schade" klaar ligt volledig binnen de toegewezen stack en nooit SEGVs. Hoe dan ook, je beuken spul moet je niet.

Verder ben ik niet zeker dat een SEGV (per definitie) is altijd te wijten aan schrijft. Er is een tekst en data segment en ik vermoed dat een poging om de tekst te lezen segment kan ook een SEGV in sommige besturingssystemen veroorzaken.