
		paulo1205
		
		(usa Ubuntu)
		
		Enviado em 11/09/2013 - 00:56h 
		clodoaldoPeres escreveu:
Cara este teu código tah bem estranho. Quando se trabalha com arquivo deve se usar algumas funções importantes como fflush() - limpar o buffer pois a cada leitura stdin pode estar sujo comprometendo a veracidade da informação, ferror() - pois as operações com arquivo podem gerar erros a qualquer instante,etc. Sugiro que você abra teu arquivo em modo binário (para mim é muito melhor para trabalhar, se possivel) usando fopen com "rb" e use um ponteiro com o tamanho total do teu arquivo (você consegue ter o tamanho do arquivo com a função ftell(<ponteiro de arquivo>)) e use fread(void *buffer,size_t <qntd de bytes a serem lidos>,1,<ponteiro de arquivo>) passando o um ponteiro de char alocado com malloc ( p = (char*) malloc(<tamanho do arquivo> * char) ) e aí o teu ponteiro de char vai ter todo o teu arquivo então vc pode fechar o arquivo com fclose()/close() e o teu arquivo vai estar em buffer aí é soh navegar nele usando os indices como se fosse um vetor de char's 
Meu caro,
Cuidado com as coisas que você diz.  Observe que:
1) Oficialmente (i.e. de acordo com o padrão do C em suas três revisões: 1989/1990, 1999 e 2011), 
fflush() nunca se destinou a limpar buffers de leitura, mas tão somente a forçar a gravação imediata (e não o descarte!) de informação em streams 
de saída.  É, portanto, JUSTAMENTE O OPOSTO do que você afirmou.  (A invenção estúpida de usar 
fflush() em buffers de entrada, particularmente 
stdin, foi uma cretinice implementada 
antes de existir um padrão para o C nos compiladores voltados para MS-DOS, cujo buffer de teclado se limitava a apenas quinze caracteres, e portanto tinha um funcionamento relativamente bem comportado e definido.  Só que essa porcaria sobreviveu, por questões de compatibilidade com implementações passadas, mesmo após a padronização da linguagem C e sua biblioteca.  Essa desgraça acabou incorporada nos compiladores para Windows e infelizmente foi importada recentemente também para o Linux, cujos buffers de teclado podem ser arbitrariamente longos e podem, portanto, nunca ser satisfatoriamente ou controladamente esvaziados.)
2) Ele está testando, sim, o sucesso da leitura, ao tomar o valor de retorno de 
fgets() e verificar se ele é nulo.  Se para ele não fizer diferença entre não conseguir ler por se ter chegado ao fim do arquivo ou em decorrência de algum erro (o que, aliás, é uma situação não muito comum em operações de leitura, especialmente num sistema monoprogramado), por que ele deveria testar o que não lhe interessa?
3) A julgar por outra postagem do mesmo autor, ele parece estar usando Windows.  No Windows, se ele quiser trabalhar com arquivos de texto, é bom que ele NÃO USE "rb", mas sim somente "r", porque as funções de leitura e escrita de texto fazem conversões entre representações internas de fim de linha e a representação usada pelo sistema operacional.  No mundo UNIX, "r" e "rb" são equivalentes, mas nos mundos Microsoft e MacOS, não.
4) É muito perigoso sugerir ler todo o arquivo para a memória.  Você sabe o tamanho do arquivo?  Sabe quanto de memória o programa tem disponível?  Então é mais seguro trabalhar com arquivos, lendo linha a linha (e limitando mesmo o tamanho de cada linha, como ele fez).
5) O programa dele é mesmo voltado a trabalhar linha a linha.  Assim sendo, ainda que ele estivesse trabalhando com tudo em memória, seria mais simples ter um array de linhas do que um megabuffer de caracteres individuais.