Escrevendo o caos em C
Existem formas simples de se descrever o caos. Este artigo mostra alguns pequenos exemplos de como provocar o caos em C.
[ Hits: 41.885 ]
Por: Ronaldo Faria Lima em 21/06/2004
Variáveis globais: o código não aproveitável
Assim como o goto e os long jumps, existe um recurso também polêmico que
são as variáveis globais. As variáveis globais são variáveis declaradas fora
de qualquer escopo de função e, por este motivo, podem ser acessadas de
qualquer lugar do seu programa.
À primeira vista, é um recurso interessante, pois pode-se salvar na pilha global todo e qualquer valor que seu programa utiliza. Porém, as variáveis globais sofrem de um efeito colateral muito grave: todo o reaproveitamento do código que as usam fica comprometido.
Outro efeito colateral grave é a concorrência. Por serem globais e por estarem acessíveis por todas as partes do código, uma determinada função pode alterar o valor desta variável de forma inesperada. A situação se complica ainda mais se tivermos várias linhas de execução dentro do programa, ou seja, várias threads. Uma thread poderá sobrescrever um valor salvo por outra thread em uma variável global de forma assíncrona e inesperada. Isso significa dizer que temos aqui um bug de difícil solução.
Existe, no entanto, uso para as variáveis globais. Imagine que você está escrevendo um handle de eventos assíncronos. Este handle irá sinalizar ao programa que um determinado sinal ocorreu. Ao ocorrer este sinal, o handle irá setar um flag que informará ao restante do programa que o mesmo precisa finalizar. Veja o exemplo:
À primeira vista, é um recurso interessante, pois pode-se salvar na pilha global todo e qualquer valor que seu programa utiliza. Porém, as variáveis globais sofrem de um efeito colateral muito grave: todo o reaproveitamento do código que as usam fica comprometido.
Outro efeito colateral grave é a concorrência. Por serem globais e por estarem acessíveis por todas as partes do código, uma determinada função pode alterar o valor desta variável de forma inesperada. A situação se complica ainda mais se tivermos várias linhas de execução dentro do programa, ou seja, várias threads. Uma thread poderá sobrescrever um valor salvo por outra thread em uma variável global de forma assíncrona e inesperada. Isso significa dizer que temos aqui um bug de difícil solução.
Existe, no entanto, uso para as variáveis globais. Imagine que você está escrevendo um handle de eventos assíncronos. Este handle irá sinalizar ao programa que um determinado sinal ocorreu. Ao ocorrer este sinal, o handle irá setar um flag que informará ao restante do programa que o mesmo precisa finalizar. Veja o exemplo:
#include <signal.h>
#include <stdio.h>
static volatile int signaled = 0x0;
static void handle (int sig) {
signaled = 0x1;
}
static int sigreceived (void) {
return signaled;
}
int main (void) {
signal (SIGTERM, handle);
for (; ! sigreceived (); ) ;
return 0;
}
#include <stdio.h>
static volatile int signaled = 0x0;
static void handle (int sig) {
signaled = 0x1;
}
static int sigreceived (void) {
return signaled;
}
int main (void) {
signal (SIGTERM, handle);
for (; ! sigreceived (); ) ;
return 0;
}
Este programa finaliza somente se receber um sigterm. No UNIX, basta executar o programa kill com a opção -TERM informando o pid do programa para vê-lo finalizar com suavidade. Neste caso, não há como evitar-se a variável global. É uma boa idéia, no entanto, mascarar o acesso à variável global usando-se uma função getter. No exemplo, a função sigreceived implementa um getter. No exemplo, o getter fica um pouco sem sentido, por que estamos dentro da mesma unidade de tradução. No entanto, se tivermos várias unidades de tradução, o getter faz muito sentido, pois evita o acesso direto à variável global.
Páginas do artigo
1. A polêmica2. O famigerado goto
3. Longjump: O goto não local
4. Variáveis globais: o código não aproveitável
5. Conclusão
Outros artigos deste autor
Como funcionam os alocadores de memória do STD C?
Programando com uma granada de mão: uma visão da linguagem C
Leitura recomendada
Criando um sistema operacional com ASM e C++
Reprodução de arquivos WAV com SDL_mixer e linguagem C
Utilizando a biblioteca NCURSES - Parte II
Programando com uma granada de mão: uma visão da linguagem C
Comentários
[1] Comentário enviado por removido em 21/06/2004 - 08:58h
Muito interessante o artigo! Nas universidades (pelo menos na minha) os professores de linguagem de programação ensinam como evitar estes "desastres"... eu acho isso muito válido! Já que os programadores de hoje, mais do que nunca, precisam levar em consideração a segurança da informação que seu programa vai manipular, tendo que procurar evitar ao máximo qualquer possibilidade de falha.
Muito interessante o artigo! Nas universidades (pelo menos na minha) os professores de linguagem de programação ensinam como evitar estes "desastres"... eu acho isso muito válido! Já que os programadores de hoje, mais do que nunca, precisam levar em consideração a segurança da informação que seu programa vai manipular, tendo que procurar evitar ao máximo qualquer possibilidade de falha.
[2] Comentário enviado por jllucca em 21/06/2004 - 16:39h
Muito legal o artigo!
Na verdade não esperava menos de ti! :D
Continue assim :))
[]'s
Muito legal o artigo!
Na verdade não esperava menos de ti! :D
Continue assim :))
[]'s
[3] Comentário enviado por engos em 23/06/2004 - 16:12h
Achei a visão um pouco limitada nos exemplos, todavia o artigo está muito bom.
É sempre bom divulgar esse tipo de conhecimento, pois a maioria das pessoas que sabem que não devem usar, não possuem a menor idéia da razão de não usar.
Artigo muito interessante e útil, parabéns.
Achei a visão um pouco limitada nos exemplos, todavia o artigo está muito bom.
É sempre bom divulgar esse tipo de conhecimento, pois a maioria das pessoas que sabem que não devem usar, não possuem a menor idéia da razão de não usar.
Artigo muito interessante e útil, parabéns.
[5] Comentário enviado por ron_lima em 11/10/2004 - 20:10h
A declaração é complicada. Entendi que é um casting que dereferencia um pointer para função void. Está correto?
A declaração é complicada. Entendi que é um casting que dereferencia um pointer para função void. Está correto?
[6] Comentário enviado por ron_lima em 12/10/2004 - 06:31h
Complementando... Esta declaração é uma tentativa de ativação de código no endereço zero, ou seja, antes da função main nos sistemas operacionais modernos. O efeito é imediato: falha de segmentação.
Complementando... Esta declaração é uma tentativa de ativação de código no endereço zero, ou seja, antes da função main nos sistemas operacionais modernos. O efeito é imediato: falha de segmentação.
[7] Comentário enviado por voulogarso1vez em 02/03/2005 - 22:43h
Faltou dizer que o setjmp/longjmp pode ser usado pra simular exceções (try/catch), apesar de difícil de fazer de forma segura (sem vazamento de memória, por exemplo). Quanto aos signals, junto com o longjump, eles são um outro canto escuro da linguagem... volatile, sig_atomic_t, sempre fico na dúvida sobre o que realmente é necessário pra deixar o código que usa esses recursos realmente portável e de acordo com os padrões.
Faltou dizer que o setjmp/longjmp pode ser usado pra simular exceções (try/catch), apesar de difícil de fazer de forma segura (sem vazamento de memória, por exemplo). Quanto aos signals, junto com o longjump, eles são um outro canto escuro da linguagem... volatile, sig_atomic_t, sempre fico na dúvida sobre o que realmente é necessário pra deixar o código que usa esses recursos realmente portável e de acordo com os padrões.
[8] Comentário enviado por ron_lima em 06/03/2005 - 07:43h
A idéia inicial do setjmp e do longjmp não é simular o tratamento de exceções mas é realizar o que é chamado de "goto não local". Estas funções fazem um rewind da pilha, fazendo qualquer empilhamento que tenha ocorrido no programa retornar a uma posição salva anteriormente. É uma ferramenta poderosa e, no entanto, extremamente perigosa, pois pode ocasionar falhas como vazamentos de memória difíceis de serem encontradas. Os sinais são uma coisa muito interessante. Eles residem na área da programação assíncrona. Nunca se sabe o que o programa vai estar fazendo quando receber um sinal. Normalmente é interessante, em sistemas unix, programar um aplicativo para tratar de forma adequada determinado sinal para que o mesmo finalize o que está fazendo sem problemas. Normalmente programa-se handles para os sinais SIGHUP para reinicialização e SIGTERM para finalização.
A idéia inicial do setjmp e do longjmp não é simular o tratamento de exceções mas é realizar o que é chamado de "goto não local". Estas funções fazem um rewind da pilha, fazendo qualquer empilhamento que tenha ocorrido no programa retornar a uma posição salva anteriormente. É uma ferramenta poderosa e, no entanto, extremamente perigosa, pois pode ocasionar falhas como vazamentos de memória difíceis de serem encontradas. Os sinais são uma coisa muito interessante. Eles residem na área da programação assíncrona. Nunca se sabe o que o programa vai estar fazendo quando receber um sinal. Normalmente é interessante, em sistemas unix, programar um aplicativo para tratar de forma adequada determinado sinal para que o mesmo finalize o que está fazendo sem problemas. Normalmente programa-se handles para os sinais SIGHUP para reinicialização e SIGTERM para finalização.
[9] Comentário enviado por elgio em 31/08/2007 - 13:28h
Muito bom este tema.
Só uma ressalva: tua função alternatica para strcpy tem um bug: não copia o 0 final. Que tal esta:
char * strcpy (char * dest, const char * orig)
{
const char *o=orig;
char *d=dest;
while (*d++ = *o++);
return (dest);
}
Muito bom este tema.
Só uma ressalva: tua função alternatica para strcpy tem um bug: não copia o 0 final. Que tal esta:
char * strcpy (char * dest, const char * orig)
{
const char *o=orig;
char *d=dest;
while (*d++ = *o++);
return (dest);
}
[10] Comentário enviado por ron_lima em 31/08/2007 - 13:36h
De fato. Eis a versão corrigida:
char * strcpy (char * dest, const char * orig) {
const char * o;
char * d;
for (o=orig, d=dest; *o != '\ 0' ; ++o, ++d) {
*d = *o;
}
*d = 0; /* Entenda-se aqui o barra zero. Aparentemente há um problema no site. */
return dest;
}
A sua versão funciona adequadamente também (faltou um ; depois do return) apesar de ser menos clara. Seria possível criar-se uma versão ainda mais reduzida, partindo-se da sua:
char * strcpy (char * dest, const char * orig) {
char *d=dest;
while (*d++ = *orig++)
;
return (dest);
}
Considerando-se que os otimizadores atuais deixam o código com a mesma performance, eu optaria por manter a versão mais clara.
De fato. Eis a versão corrigida:
char * strcpy (char * dest, const char * orig) {
const char * o;
char * d;
for (o=orig, d=dest; *o != '\ 0' ; ++o, ++d) {
*d = *o;
}
*d = 0; /* Entenda-se aqui o barra zero. Aparentemente há um problema no site. */
return dest;
}
A sua versão funciona adequadamente também (faltou um ; depois do return) apesar de ser menos clara. Seria possível criar-se uma versão ainda mais reduzida, partindo-se da sua:
char * strcpy (char * dest, const char * orig) {
char *d=dest;
while (*d++ = *orig++)
;
return (dest);
}
Considerando-se que os otimizadores atuais deixam o código com a mesma performance, eu optaria por manter a versão mais clara.
[11] Comentário enviado por elgio em 31/08/2007 - 13:38h
Oi. Já percebi que o VOL estraga alguns caracteres. o CONTRA-BARRA ZERO por exemplo...
Chato isto...
tente por apenas *d = 0
(se funcionar)
Oi. Já percebi que o VOL estraga alguns caracteres. o CONTRA-BARRA ZERO por exemplo...
Chato isto...
tente por apenas *d = 0
(se funcionar)
[12] Comentário enviado por elgio em 31/08/2007 - 13:42h
Correto. Minha versão é menos clara e de propósito: Envio ela para meus alunos como desafio do que ela faz, depois que mostrei ponteiros, evidentemente.
Até lá, o que eles conhecem de strcpy é isto :-(
int strcpy (char d[], char o[])
{
int i;
for (i = 0; o[i] != 0; i++){
d[i] = o[i];
}
d[i] = 0;
return (i); /* no caso retorna o numero de cars copiados (tamanho) */
}
Correto. Minha versão é menos clara e de propósito: Envio ela para meus alunos como desafio do que ela faz, depois que mostrei ponteiros, evidentemente.
Até lá, o que eles conhecem de strcpy é isto :-(
int strcpy (char d[], char o[])
{
int i;
for (i = 0; o[i] != 0; i++){
d[i] = o[i];
}
d[i] = 0;
return (i); /* no caso retorna o numero de cars copiados (tamanho) */
}
[13] Comentário enviado por elgio em 31/08/2007 - 13:50h
Aproveitando o assunto (porque eu adoro C e apesar do teu artigo ser ANTIGO, eu só o descobri hoj. hehehehe).
Outro fato no C que PODE VIR A SER UM DESASTRE, se não feito com cuidado, é a manipulação de números de ponto flutuante. Nem estou falando da velha pegadinha:
int x=10;
double z;
z = x/4;
/* z infelizmente vai ter 2 e não 2.5 */
Mas eu envio também como desafio aos alunos (com a intenção de mostrar os perigos) este pra lá de polêmico trecho de código:
int a;
a = 200;
a = (a * 0.7) + a;
Isto deveria dar 340, pois 200 * 0.7 da 140 e não haveria perda de casas decimais, certo? Pois dá 339!!
Cara, acho este comportamento o mais interessante que já vi e, é claro, a explicação é perfeitmante lógica!!
Aproveitando o assunto (porque eu adoro C e apesar do teu artigo ser ANTIGO, eu só o descobri hoj. hehehehe).
Outro fato no C que PODE VIR A SER UM DESASTRE, se não feito com cuidado, é a manipulação de números de ponto flutuante. Nem estou falando da velha pegadinha:
int x=10;
double z;
z = x/4;
/* z infelizmente vai ter 2 e não 2.5 */
Mas eu envio também como desafio aos alunos (com a intenção de mostrar os perigos) este pra lá de polêmico trecho de código:
int a;
a = 200;
a = (a * 0.7) + a;
Isto deveria dar 340, pois 200 * 0.7 da 140 e não haveria perda de casas decimais, certo? Pois dá 339!!
Cara, acho este comportamento o mais interessante que já vi e, é claro, a explicação é perfeitmante lógica!!
[14] Comentário enviado por elgio em 31/08/2007 - 13:53h
Só para finalizar:
http://www.inf.ufrgs.br/~elgios/linux/programacao_C/problema1.html
[]'s
PS: teu artigo já entrou no meu favoritos
Só para finalizar:
http://www.inf.ufrgs.br/~elgios/linux/programacao_C/problema1.html
[]'s
PS: teu artigo já entrou no meu favoritos
[15] Comentário enviado por ron_lima em 31/08/2007 - 14:25h
Sim, pelo fato de a * 0.7 resultar em 139.999999999997, efeito dos números em ponto flutuante.
Uma variação bacana do seu strcpy que determina quantos caracteres foram copiados poderia ser:
int strcpy (char *a, const char *b) {
const char *c = b;
while (*a++ = *c++)
;
return (c - b - 1);
}
Esta versão é também interessante pela adição da aritmética de ponteiros ao final. Mas ainda acho a função abaixo uma das mais interessantes, apesar de não aconselhar o uso de construções deste tipo:
void func (int *a, int *b) {
*a ^= *b;
*b ^= *a;
*a ^= *b;
}
Sim, pelo fato de a * 0.7 resultar em 139.999999999997, efeito dos números em ponto flutuante.
Uma variação bacana do seu strcpy que determina quantos caracteres foram copiados poderia ser:
int strcpy (char *a, const char *b) {
const char *c = b;
while (*a++ = *c++)
;
return (c - b - 1);
}
Esta versão é também interessante pela adição da aritmética de ponteiros ao final. Mas ainda acho a função abaixo uma das mais interessantes, apesar de não aconselhar o uso de construções deste tipo:
void func (int *a, int *b) {
*a ^= *b;
*b ^= *a;
*a ^= *b;
}
[16] Comentário enviado por elgio em 31/08/2007 - 14:33h
Adorei.
Um swapp usando XOR.
Ta entrando na minha lista de desafios para os alunos.
Já que iniciamos um odisséia de "troca de figurinhas":
int main()
{
a=22;
a= a++ + a++;
a=22;
a= ++a + ++a;
a=22;
a= a++ + ++a;
a=22;
a= ++a + a++;
}
Mas este é o último :-D
Trocamos por email, senão vou queimar meus desafios todos aqui!!
[]'s
Adorei.
Um swapp usando XOR.
Ta entrando na minha lista de desafios para os alunos.
Já que iniciamos um odisséia de "troca de figurinhas":
int main()
{
a=22;
a= a++ + a++;
a=22;
a= ++a + ++a;
a=22;
a= a++ + ++a;
a=22;
a= ++a + a++;
}
Mas este é o último :-D
Trocamos por email, senão vou queimar meus desafios todos aqui!!
[]'s
[17] Comentário enviado por f_Candido em 13/10/2007 - 23:32h
Bem exposto o conteúdo. Ficou muito Bom.
Parabéns.
Bem exposto o conteúdo. Ficou muito Bom.
Parabéns.
[18] Comentário enviado por Chrys em 27/01/2008 - 15:52h
Contudo sobre a parte de static e variável global, neste caso nem exerce realmente a função de variável global, já que o tipo static definirá que essa variável só poderá ser vista dentro deste arquivo, em nenhum outro arquivo poderá acessar essa variável diretamente, o que é um procedimento seguro, tornando a variável global apenas no arquivo em questão e sendo até recomendado esse uso de getter.
Então se nesse caso você tiver uma variável static dentro do arquivo file.c e quiser acessa-la através do arquivo tentando.c, pode esquecer, pois diretamente fica "impossível" acessar, surgindo os famosos gets e sets da vida, acho que é a parti daí que sai o procedimento de segurança de código.
Uma dúvida é possível se fazer funções statics em C?
Contudo sobre a parte de static e variável global, neste caso nem exerce realmente a função de variável global, já que o tipo static definirá que essa variável só poderá ser vista dentro deste arquivo, em nenhum outro arquivo poderá acessar essa variável diretamente, o que é um procedimento seguro, tornando a variável global apenas no arquivo em questão e sendo até recomendado esse uso de getter.
Então se nesse caso você tiver uma variável static dentro do arquivo file.c e quiser acessa-la através do arquivo tentando.c, pode esquecer, pois diretamente fica "impossível" acessar, surgindo os famosos gets e sets da vida, acho que é a parti daí que sai o procedimento de segurança de código.
Uma dúvida é possível se fazer funções statics em C?
[19] Comentário enviado por ron_lima em 29/01/2008 - 08:44h
A variável declarada como estática (static) é sempre global, mesmo que não seja possível acessá-la de outra unidade de tradução. Mesmo quando declarada dentro de uma função, ela será alocada dentro da pilha global do programa.
Quando declarada fora de blocos, ela é global na unidade de tradução na qual foi declarada. Portanto, ela continua sendo uma variável global.
Da mesma forma, é possível declarar-se funções com o mesmo especificador de armazenamento. As funções "static" também são visíveis apenas dentro da unidade de tradução onde são declaradas e definidas.
Variável global é receita certa para programas altamente acoplados e de difícil manutenção, mesmo que o acesso seja controlado por "getters" e "setters". O ideal é não usá-las. Sempre é possível fornecer os dados necessários através de parâmetros de função.
Contudo, há casos em que é necessário o uso de variáveis globais. Por exemplo, no caso de eventos assíncronos que ocorram no seu programa - por exemplo, um sinal - que precisam ser tratados e ter seu estado controlado. Normalmente os handlers de eventos assíncronos são funções que não têm contato com o restante do programa - um handle de sinal é uma função void que recebe como parâmetro o número identificador do sinal que ocorreu. Para este caso, é indicado a variável global para que o estado do programa seja conhecido depois da ocorrência do evento assíncrono.
A variável declarada como estática (static) é sempre global, mesmo que não seja possível acessá-la de outra unidade de tradução. Mesmo quando declarada dentro de uma função, ela será alocada dentro da pilha global do programa.
Quando declarada fora de blocos, ela é global na unidade de tradução na qual foi declarada. Portanto, ela continua sendo uma variável global.
Da mesma forma, é possível declarar-se funções com o mesmo especificador de armazenamento. As funções "static" também são visíveis apenas dentro da unidade de tradução onde são declaradas e definidas.
Variável global é receita certa para programas altamente acoplados e de difícil manutenção, mesmo que o acesso seja controlado por "getters" e "setters". O ideal é não usá-las. Sempre é possível fornecer os dados necessários através de parâmetros de função.
Contudo, há casos em que é necessário o uso de variáveis globais. Por exemplo, no caso de eventos assíncronos que ocorram no seu programa - por exemplo, um sinal - que precisam ser tratados e ter seu estado controlado. Normalmente os handlers de eventos assíncronos são funções que não têm contato com o restante do programa - um handle de sinal é uma função void que recebe como parâmetro o número identificador do sinal que ocorreu. Para este caso, é indicado a variável global para que o estado do programa seja conhecido depois da ocorrência do evento assíncrono.
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Como renomear arquivos de letras maiúsculas para minúsculas
Imprimindo no formato livreto no Linux
Vim - incrementando números em substituição
Efeito "livro" em arquivos PDF
Como resolver o erro no CUPS: Unable to get list of printer drivers
Tópicos
Não to conseguindo resolver este problemas ao instalar o playonelinux (1)
Excluir banco de dados no xampp (1)
Top 10 do mês
-
Xerxes
1° lugar - 64.974 pts -
Fábio Berbert de Paula
2° lugar - 50.311 pts -
Buckminster
3° lugar - 17.274 pts -
Mauricio Ferrari
4° lugar - 15.233 pts -
Alberto Federman Neto.
5° lugar - 13.933 pts -
Diego Mendes Rodrigues
6° lugar - 13.350 pts -
Daniel Lara Souza
7° lugar - 12.655 pts -
Andre (pinduvoz)
8° lugar - 10.345 pts -
edps
9° lugar - 10.635 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 10.451 pts
Scripts
[Python] Automação de scan de vulnerabilidades
[Python] Script para analise de superficie de ataque
[Shell Script] Novo script para redimensionar, rotacionar, converter e espelhar arquivos de imagem
[Shell Script] Iniciador de DOOM (DSDA-DOOM, Doom Retro ou Woof!)
[Shell Script] Script para adicionar bordas às imagens de uma pasta
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
