Algo estranho se passa aqui... - C - Portugal-a-Programar
Algo estranho se passa aqui...
Por Cypher, 28 de Agosto de 2007 em C
Tenho uma funçao que dentro dela invoca uma 2 funçao
void cod_bitwise (unsigned short index,unsigned short lenght,unsigned short ch){
unsigned short bit_final=0;
index<<=11;
lenght<<=7;
bit_final=(index | lenght | ch);
send_2_file (bit_final);
//   printf("bitwaise =%u.",bit_final);
//   printf("size of do int =%d",sizeof(short));
E o problema é no decorrer do programa a funçao cod_bitwise chama a funçao send_2_file, mas se eu meter outra instruçao a seguir desta send_2_file (bit_final); faz, tudo bem
senao tiver nenhuma instruçao depois do send_2_file se meter logo o } nao faz nada...
ou seja da maneira que esta aqui nao me faz nada
ja esprimentei por com returns e nada...como é que resolvo isto... ?
nessa função não vejo nenhum problema... se calhar o problema está na send_2_file.
é melhor mostrares o código da função send_2_file também não vejo nenhum problema aí...
nao da funçao send_2_file, nao é mesmo... isso tenho a certeza...
mas também já está o problema resolvido afinal dá mesmo com um return....
int cod_bitwise (unsigned short index,unsigned short lenght,unsigned short ch){
Podes ter "resolvido" o problema, mas não ficaste a perceber porquê...
void send_2_file(unsigned short bit){
if ( (fp = fopen(n_fich, "a+")) != NULL){
fwrite(&bit, sizeof(unsigned short), 1, fp);
printf("Impossivel abrir o ficheiro\n\n");
o n_fich é uma string... não é dai o problema.
... porque estava a usar C ? :hmm:
?? não percei essa...
const char n_fich[] = "coiso.txt";
unsigned short a ,b,c;
cod_bitwise(a,b,c);
:hmm: este código compilado no gcc funciona, ao contrário do que te acontece...
o meu palpite é que está a haver algum problema do compilador no protótipo e/ou epílogo da função cod_bitwise , mas não sei explicar porquê :bored:
já agora.. que compilador estás a usar ? Eu estou em windows com o djgpp
um debugger é capaz de ajudar a descobrir o problema...
Também concordo em como usar um debugger é o melhor para perceberes onde está o teu erro. Podias colocar aqui o source file completo e já agora que comando usas para compilar o teu código. Não me parece que mudares o tipo de retorno de uma função de
e colocando um
que isso vá alterar o que quer que seja em termos de execução... :dontgetit: mas só mesmo vendo o código todo e fazendo debug
Não me parece que mudares o tipo de retorno de uma função de para e colocando um que isso vá alterar o que quer que seja em termos de execução... :dontgetit:
[ infelizmente? ] poder, pode. Aqueles que tiveram assembly sabem o que é o protótipo e o epílogo duma função. Neste caso o problema parece ser o epílogo (quando a função retorna), o facto de ser void ou retornar um inteiro é diferente.
Se calhar o que acontece é k o compilador não está a fazer o epílogo correctamente no caso de uma função void, porque qualquer função tem de retornar ao ponto em que foi chamada. Mas também não me parece que um compilador possa ter este problema
O C às vezes parece que fica possesso...
Já aconteceu a um colega meu, que após a optimização do código de uma função ficou com algumas variáveis que estava a usar antes e que já não usava mais. Ao tirar a declaração da variável (era um int) o programa craxava, com a declaração da variável funcionava às mil maravilhas.
O que eu queria dizer era que mal o fluxo de execução passe por essa função (que foi alterada para retornar um int ), não é por colocar um return 0 que vai fazer com que a execução subitamente consiga sair dessa função quando isso não acontecia anteriormente (quando não retornava nenhum tipo de dado)!! Logicamente que uma função que retorna seja que tipo de dados for, tem que retornar e o fluxo de execução tem que continuar obviamente como disseste, se não ocorrerem erros entretanto. Se o código for correctamente programado e compilado, essa função cod_bitwise funciona perfeitamente bem mesmo não retornando nenhum tipo de dados, como te mostra o exemplo do mogers. Não me parece que seja qualquer problema com o prólogo ou o epílogo, muitas das vezes o problema em questão é bem mais simples do que o que pensamos.
Só naquela... já que não parece existir problema em lado nenhum.
Retira o fclose(fp) que está a mais.
Bem ate posso disponibilizar o programa ... mas ja leva mais de 500 linhas de codigo, pessoalmente nao acho muito, acho muito sim tar a analizar um programa de inicio assim...
já agora estou a utilizar o Dev C++... mas acontece me uma cena engraçada ja esprimentei compilar no c++ 3.0 e com o gcc nu Ubunto e dá bem enquanto no dev nao faz nada... agora se meter o return funciona em todos...
Quando o programador faz erros, o C queixa-se.
Até te digo o que aconteceu aí: estavas a aceder a uma posição de memória ilegal num vector, por exemplo v[5] num "int v[5];". Como tinhas declarado o outro inteiro logo de seguida, ficaram contíguos na memória e ele retornava esse inteiro no v[5], logo não dava erro. Ao retirar a sua declaração, passa a dar.
O C não fica possesso. É uma linguagem demasiado aperfeiçoada para ter problemas desses. O programador é que por vezes faz asneiras e não sabe porquê.
apesar de tudo, não é impossível que os processadores tenham bugs... mesmo o gcc (que deve ser o melhor que aí anda) deve ter alguns, mas isto acontece com todas as linguagens.
Claro que é possível os compiladores terem bugs, mas não me parece que seja quem está a aprender, no dia-a-dia, que os encontre. São as excepções, e a termos de bugs dos compiladores, devido ao uso intensivo, diria que C ainda está mais protegido do que qualquer outra linguagem..
Obvio, daí dizer parece.. porque segundo o compilador estava tudo bem.
E mais, a função em questão não trabalhava com apontadores (arrays incluídos), simplesmente algures noutra parte do programa o meu colega devia estar a fazer algo errado. Mas deu para dar umas boas gargalhadas visto que o trabalho em questão tinha-se a liberdade de fazer em qualquer linguagem e ele foi dos poucos que optou por C e um simples int x; dava erro
É claro que ele ficou a olhar para o código durante 2 dias e depois lá resolveu fazer um rm -f e perder mais um par de dias a reescrever tudo o que já tinha feito e ficou tudo a funcionar às mil maravilhas.
Isso é verdade de todas as linguagens que conheço o C parece ser o mais perfeito de todas... Pascal, um simples utilizador, encontra logo um pouco de erros, nem é necessário usar muito para aparecer logo os primeiros erros, o delphi será uma boa escolha para substituir o pascal ... VB nem devia comentar gosto da linguagem... fazem-se programas em pouco tempo, e com bom interface ... agora erros também é ele o Rei :biggrin: , e assim os outros compiladores igual, menos ou mais lá tem os seus erros...
Agora não sei se é pela linguagem C ter a dimensao, quantidade de programadores de C, que chega a ser a mais perfeita ( em termos de erros ) que todas as outras...mas lá ha-de de ter os seus erros, concordo com o Warrior não os deve encontrar quem está a aprender, no dia-a-dia.
Para mim não ha nenhum programa perfeito ( um bocado do meu lado perfeccionista )
por exemplo v[5] num "int v[5];".
Onde? Não encontro declarações de vectores no código.
não estao a falar do meu codigo... foi um exemplo que o Warrior deu...
o Warrior tava a falar do problema referido pelo Betovki
Não podia estar mais de acordo :biggrin: Realmente, muita gente culpa sempre o C quando tem problemas "inexplicáveis" , quando o erro está do nosso lado.
No ultimo semestre tive uma cadeira que misturava C com funções assembly, e nas funções assembly assediamos a variáveis e funções definidas no código em C ( código principal) , aí sim era uma mina de erros desse género. Nestas alturas com um debugger podemos gastar 1 horita (nem sei se tanto), "à mão" como o amigo do Betovski gastou 2 dias :hmm:
já fiz com que o gcc abortasse na compilação, por estar a aceder (propositadamente) a posições fora do vector. na melhor das hipóteses, o gcc devia avisar que tinha um erro no código ou algo assim, mas não, abortou!