Vai realmente escrever muitas vezes, pena que a variável inteira i vai estourar assim que atingir o limite da arquitetura. No lugar use um while (true).
Deixa a menina em paz. E daí que a variável i vai estourar. O que você acha que vai acontecer? Quando ele atingir o maior número possível, ele vai estourar e voltar para o menor número possível, e continuar incrementando normalmente. Não vai dar nenhum erro no programa.
E mesmo assim, como ela não está usando a variável i, o gcc é inteligente o suficiente para eliminar essa variável do código compilado mesmo sem ativar otimizações explicitamente. Veja como fica o código assembly x86 compilado:
É que eu prefiro não correr o risco do amor acabar porque eu confiei no compilador, prefiro escrever código bom. Eu e minha esposa estamos juntos a 10 anos, naquela época o gcc não era tao bom, imagina se eu acordo um dia e ela me diz "segmentation fault" quero o divorcio. hehehe Melhor escrever código bom, sempre.
Mas isso não tem nada a ver com o compilador. Eu desconheço qualquer arquitetura na qual um estouro de número inteiro cause o disparo de alguma interrupção de erro pelo processador. Isso seria até problema, pois existem muitos códigos de processamento de sinais em C que assumem o comportamento de wrap-around dos inteiros!
Se não acredita, experimente esse código:
#include <stdint.h> #include <stdio.h> int main() { uint8_t c = 0xff; c++; printf("%d\n", c); return 0; }
Você obterá o resultado zero, e não ocorrerá erro nenhum no programa.
Mesmo que o processador seja de alguma arquitetura maluca que tenha algum comportamento bizarro, o padrão da linguagem C garante o comportamento wrap-around pelo menos para inteiros sem sinal. Para inteiros com sinal o comportamento de wrap-around não é garantido, ou seja, o valor da variável após um estouro não é garantido dependendo da arquitetura, mas nunca resulta em fechamento do programa. No caso de arquiteturas x86, x86_64, ppc, arm, mips, sparc e outras, ocorre o comportamento que eu descrevi.
Outra coisa, "segmentation fault" não tem nada a ver com essa história.
6 comentários:
Vai realmente escrever muitas vezes, pena que a variável inteira i vai estourar assim que atingir o limite da arquitetura. No lugar use um while (true).
@crg,
Deixa a menina em paz. E daí que a variável i vai estourar. O que você acha que vai acontecer? Quando ele atingir o maior número possível, ele vai estourar e voltar para o menor número possível, e continuar incrementando normalmente. Não vai dar nenhum erro no programa.
E mesmo assim, como ela não está usando a variável i, o gcc é inteligente o suficiente para eliminar essa variável do código compilado mesmo sem ativar otimizações explicitamente. Veja como fica o código assembly x86 compilado:
580:
lea -0x1968(%ebx),%eax
mov %eax,(%esp)
call 418
addl $0x1,-0xc(%ebp)
jmp 580
Viu? Cadê a variável i? Sumiu!
Ou seja, o código dela acabou ficando totalmente equivalente a se ela usasse um while(1) (em C) ou while(true) (em C++).
É que eu prefiro não correr o risco do amor acabar porque eu confiei no compilador, prefiro escrever código bom. Eu e minha esposa estamos juntos a 10 anos, naquela época o gcc não era tao bom, imagina se eu acordo um dia e ela me diz "segmentation fault" quero o divorcio. hehehe Melhor escrever código bom, sempre.
@crg,
Mas isso não tem nada a ver com o compilador. Eu desconheço qualquer arquitetura na qual um estouro de número inteiro cause o disparo de alguma interrupção de erro pelo processador. Isso seria até problema, pois existem muitos códigos de processamento de sinais em C que assumem o comportamento de wrap-around dos inteiros!
Se não acredita, experimente esse código:
#include <stdint.h>
#include <stdio.h>
int main() {
uint8_t c = 0xff;
c++;
printf("%d\n", c);
return 0;
}
Você obterá o resultado zero, e não ocorrerá erro nenhum no programa.
Mesmo que o processador seja de alguma arquitetura maluca que tenha algum comportamento bizarro, o padrão da linguagem C garante o comportamento wrap-around pelo menos para inteiros sem sinal. Para inteiros com sinal o comportamento de wrap-around não é garantido, ou seja, o valor da variável após um estouro não é garantido dependendo da arquitetura, mas nunca resulta em fechamento do programa. No caso de arquiteturas x86, x86_64, ppc, arm, mips, sparc e outras, ocorre o comportamento que eu descrevi.
Outra coisa, "segmentation fault" não tem nada a ver com essa história.
Eu ri muito!!!
Mas calma, ou amor não acaba assim, as vezes trava, ou as vezes tem que comecar de novo, mas nao acaba não. Rs =*
haha também ri.
Alias acho que vou reescrever esse código e incluir suporte a multithred, depois de 10 anos já é hora de pensar em processos filhos.
Postar um comentário