Obrigado rapazes para t entrada.

N1 Bem, eu estava pensando nas mesmas linhas. Levando-lo um pouco mais longe, uma vez que j foram atribuídos 15 bytes, mesmo se eu introduzir um tampão de dizer 20 (basicamente> 15), o programa não travar.

Agora, assumindo THT k alguns pontos a localização da sede / cerca de espaço alocado para j, por que esta condição não causar uma sobrecarga e, em seguida, provocar uma SEGV?

Shouldnt SEGV ocorrer quando o meu programa acessa qualquer memória fora do seu espaço alocado? (para não falar válido / inválido addessses)

Além disso, eu reparei THT prévia para uma sprintf em 'k', uma vez que o seu valor era de stdout, e depois da string em sprintf. Talvez estes sejam tratados como endereços válidos e dentro de limites programa?

BTW, eu vim com o cenário acima accidently quando experimentam algo. Além disso, eu sei ao certo o que estou fazendo é ilegal, mas perplexes mim quando ele funciona!

É uma aplicação estrita detalhe como este é, algumas arquiteturas pode simplesmente reunir a memória virtual e adicioná-lo ao seu trabalho conjunto, especialmente se o sistema operacional que você acha que são apenas prorroga a pilha.

Também diferentes arquiteturas são mais rigorosas do que outros em relação (a) ao longo do código escrito áreas (b) acesso desalinhadas.

Você tentou imprimir o conteúdo de 'j', quando ela existe? Desde a introdução do 'j' é o que está causando o SEGV parar, então eu iria adivinhar o seu conteúdo é influenciar o resultado.

Todo mundo é tão focada em 'k', ainda estou a ver ninguém menciona 'i'. O sprintf deve atravessar qualquer conteúdo 'i' e está a apontar para que emitem para 'k'. Desconfio que 'j' e 'i' tem mais uma relação de 'j' e 'k'.

Se eu tivesse de tomar um palpite, "j" (quando existir) tem, em algum momento, um nulo terminador ( '\ 0') dentro dele, e 'i' é (em algum momento antes do SEGV) que funciona no conteúdo de 'j'. Isto, naturalmente, limita a quantidade de "lixo", você pode tanto ler e pau na unreferenced 'k' e, portanto, reduz o potencial de SEGV.

Leve 'j' para fora da imagem e do sprintf obviamente é executado em uma área de memória não deve. Meu palpite, enquanto o sprintf está percorrendo 'i' transbordamento que diabos você quer fora de 'k', porque não há terminador nulo na memória por muito tempo ou se não houver nenhuma terminador nulo perante o sprintf fica no texto segmento e no SO não gosta que violem os dados segmento.

Gostaria de testar a minha teoria, mas AIX tarolos independentemente da presença de 'j'.

poderia ser, mas, quando impresso no conteúdo do j, que era "" (como é óbvio, pois é um manequim).
Mas talvez possa haver algum lixo nos 15 bytes alocados.
U Como mencionado, deve-dump core ambas as vezes.

Além disso, é mencionado como porteiro até o SO quando / quanto ele deve ser rigoroso.

Um SEGV, por definição, quer dizer, você está tentando gravar em um segmento fora da memória alocada para você. No primeiro caso, você não tinha armazenamento atribuída, apenas apontadores, para escrever o primeiro deu-lhe a SEGV. A segunda é mais difícil de detectar um erro. Enquanto você estiver escrevendo para qualquer memória alocada para você, você não irá receber um SEGV. Seus ponteiros só acontecem ao ponto de afectar memória, neste caso, o seu j [] tabela de caracteres. Escreve bastante coisa lá, e você receberá uma SEGV ali também, quando você cair no final da sua memória alocada. O compilador e executar o tempo libs não tem idéia se pretender apontar para memória alocada, ou se, em que memória alocada pretende ponto, com seus ponteiros. Enquanto você está apontando para memória alocada, a execução, não será um problema SEGV (Você não está escrito fora da memória alocada)

Empilhamentos Tipicamente são prorrogadas por segmento violações, em vez de atribuir uma enorme pilha para um processo, põe guarda páginas abaixo dela, e quando tropeçar aqueles que cresce a pilha.

Você diria que "é óbvio", mas, em seguida, "obviamente" todos os outros ponteiros deve ser definido para NULL também. Escreva para NULL deve causar SEGV .... No entanto, se ele é ", em seguida, que é parte da razão por que a existência de 'j' você está parando de SEGV. Porque enquanto sprintf está percorrendo a string 'i' para despejar o seu conteúdo em 'k', que imediatamente bate o NULL terminador e limita o dano feito. Muito possivelmente, o "dano" feito reside inteiramente no atribuídos pilha e nunca SEGVs. De qualquer maneira, você está clobbering coisas que você não deve.

Além disso, eu não estou certo de que um SEGV (por definição) é sempre devido a escreve. Existe um texto e dados segmento e eu suspeito que uma tentativa de ler o texto segmento poderia também causar um SEGV em alguns sistemas operacionais.