Início / coding / Perguntas / 79559705
Accepted
Archsx
Asked: 2025-04-07 19:04:34 +0800 CST

O que acontece quando o segundo parâmetro de `fgets` excede o tamanho do buffer em C? [duplicado]

  • 772

Estou aprendendo C e rapidamente encontrei meu primeiro problema neste tutorial . Aqui está o código:

#include <stdio.h>
#include <stdbool.h>

static char buffer[10];

int main(int argc, char **argv) {
    puts("Lispy VERSION 0.0.0.0.1");
    puts("Press Ctrl+c to exit\n");

    while (true) {
        fputs("Lispy> ", stdout);

        fgets(buffer, 2048, stdin);

        printf("No you are a %s", buffer);
    }

    return 0;
}

Neste código, eu queria testar o que acontece se o segundo parâmetro max_countda fgetsfunção exceder o tamanho do buffer. Para minha surpresa, o programa rodou perfeitamente, sem erros, e o compilador não me avisou sobre possíveis problemas.

Usei o recurso de depuração no meu editor e descobri que se eu inserir uma string como HELLLOOOOOOOOOOOOOOOOOOOOOOO, a situação da memória fica assim:

insira a descrição da imagem aqui

Como mostrado na captura de tela acima, parece que toda a string de entrada está armazenada corretamente na memória! Também parece que o tamanho de buffernão é exatamente o que eu especifiquei (10 bytes). Se fossem 10 bytes, a linha printf("No you are a %s", buffer);deveria imprimir apenas 10 bytes, mas imprimiu a string inteira "HELLLOOOOOOOOOOOOOOOOOOOOOOOOO".

Isso significa que eu realmente acessei memória além do tamanho alocado do buffer?

c

1 respostas

  1. Best Answer

    Em geral, a linguagem C é um mecanismo para fazer o que o programador diz e não para fornecer verificações de que está sendo feito corretamente.

    Um motivo para isso é que, quando C estava sendo desenvolvido, as linguagens de programação eram relativamente novas, e cada recurso implementado exigia uma quantidade considerável de trabalho. Alguém precisava ter as ideias, planejar a solução, implementar algoritmos e escrever o código. Portanto, pouco trabalho era feito para garantir que os programas não fossem escritos além dos limites dos arrays. Esse era o trabalho do programador.

    Outro motivo é que uma característica desejável de C é sua rapidez: ela praticamente não realiza nenhum trabalho além do absolutamente necessário para o funcionamento de um programa. Adicionar verificações em tempo de execução para coisas que um programador deveria ter feito ao escrever o programa é um desperdício, pois executa muitas vezes o que deveria ter sido feito apenas uma vez.

    Portanto, o padrão C define o que acontece quando um programa usa fgetsmétodos que não transbordam o buffer passado a ele. Ele não define o que acontece quando um programa transborda o buffer. Na terminologia do padrão C, esse é um comportamento indefinido: o padrão não especifica nada sobre o que deve acontecer.

    Quando fgetsusado como você demonstrou, a consequência mais comum é que ele escreve além do array. O que acontece então depende do programa. Escrever além do array sobrescreve outros dados no programa. Em um programa simples como o que você tentou, com pouco conteúdo, nada mais era imediatamente afetado. Em um programa com mais componentes, escrever além do array pode ter interrompido outras coisas, e o programa travará ou apresentará mau funcionamento.

    Se fossem 10 bytes, a linha printf("No you are a %s", buffer);deveria imprimir apenas 10 bytes…

    Nada indica printfo tamanho buffer. Quando printfvê %s, ele detecta o fim da string procurando por um byte nulo. Como você fgetsescreveu uma string que excede o tamanho do array, printfseguiu os bytes, imprimindo cada um até encontrar um byte nulo. Havia um byte nulo após a string que você inseriu, pois fgetscoloca um byte nulo após os caracteres que lê.

    Esta é uma simples manifestação de comportamento indefinido. Você deve estar ciente de que os compiladores se tornaram sofisticados e, quando a otimização é ativada, eles podem transformar programas de maneiras que podem ser surpreendentes a princípio, portanto, o comportamento indefinido pode se manifestar de maneiras surpreendentes.

    Segundo, o compilador não deveria ser capaz de detectar esse tipo de comportamento indefinido?

    Alguns compiladores detectam esse problema específico . No entanto, não é possível que os compiladores detectem todos esses erros. Muitas vezes, o erro fgetsnão seria executado diretamente no código onde a declaração do buffer é visível. Frequentemente, o buffer seria passado para alguma outra subrotina, e essa subrotina chamaria fgets. No código visível ao compilador, não seria aparente que o comprimento usado era maior que o comprimento do buffer.

    • 7

relate perguntas