Recriei algumas das funções da biblioteca string.h [RESOLVIDO]

A promoção de char/signed char/unsigned char para int ocorre automaticamente em qualquer expressão, então você não precisa fazer conversão explícita quando calcular a diferença entre dois caracteres. Só não pode cometer o erro — e você realmente não o cometeu — de gravar o resultado numa variável que seja do tipo char/signed char/unsigned char.

Fiquei na dúvida de se, ao perguntar se faria (ênfase minha) diferença conversão de int para char, você se refere a algum outro ponto do programa, além dos quatro em que você já fez essa conversão. Refere-se?

Sua pergunta me obrigou a ler detalhadamente a respeito de algumas funções que você está tentando reimplementar, tais como strchr() e memchr(), e isso me ajudou a ter um novo olhar sobre algumas dessas funções. Eu estava tentado a opinar que, por conta da promoção automática para int na hora de avaliar expressões, a conversão explícita de int para char seria inócua, mas percebi que não é, porque essa conversão explícita pode provocar uma mudança do valor inteiro. E aí me vieram muito mais dúvidas e até alguma indignação a respeito dessas funções. Por exemplo, com relação a strchr() (e, por conseguinte, com sua versão também):

  • Se o caráter a ser buscado vai ser convertido para char na hora de varrer a string, por que ele é passado à função por um parâmetro do tipo int, em lugar de char?

        Aqui geralmente se fala sobre razões históricas. Eu até compreendo, mas não fico muito satisfeito.

  • Se várias funções do C (especialmente as declaradas em <ctype.h>, mas também outras, como fgetc() e ungetc()) limitam o escopo de caracteres àquilo que pode ser representado como unsigned char ou a EOF mais aquilo que pode ser representado como unsigned char, por que strchr() não segue a mesma convenção?

        Esta aqui meio que se contrapõe à questão anterior, pois se ali a ênfase era em deixar o comportamento da função como existe hoje mais evidente na sua assinatura, aqui se cogita mudar o comportamento atual para deixá-lo mais consistente com outras funções da biblioteca, permitindo, por exemplo, que o código abaixo, que não tem nenhum erro sintático nem incompatibilidade de tipos nem promoção automática de char ára int, não tenha mais um comportamento errado caso o fim dos dados de entrada seja atingido (para ficar mais divertido, imagine esse programa roda num sistema que empregue um conjunto de caracteres de oito bits, tal como ISO-8859-1 ou Windows CP-1252, no qual 'ÿ' vale -1 quando representado como char com sinal ou na qual EOF, que vale -1, é convertido para 255 quando é convertido para char sem sinal).

// Conta quantos caracteres digitados em sequência fazem parte do nome da cidade francesa.

unsigned counter=0;

while(strchr("L'Haÿ-les-Roses", fgetc(stdin)))

	++counter; 

  • Se a função retorna um ponteiro para dentro da string recebida caso encontre nela o caráter procurado, como pode o ponteiro devolvido ser do tipo ponteiro para caracteres não-constantes, se o parâmetro que recebe a string é um ponteiro para caracteres constantes?

        Tal anomalia faz com que o compilador aceite como válido um código como o seguinte, que é perceptivelmente absurdo e seguramente vai dar problema na hora da execução.

*strchr("Teste", 'T')='P';  // Tenta transformar a constante "Teste" em "Peste", e o compilador C aceita isso alegremente. 

        Neste ponto, pelo menos o C++ se sai um pouquinho melhor, ao definir duas versões separadas de std::strchr(): uma que recebe e retorna ponteiros para caracteres constantes, e outra que aceita ponteiros para caracteres não-constantes e retorna um ponteiro que permite modificar tais dados.

  • Também não ajuda nada:

      • Ter três tipos distintos para representar caracteres: char, signed char e unsigned char (para não mencionar outros tipos, destinados a representar conjuntos de caracteres que não cabem em oito bits ou têm regras especiais, tais como wchar_t, char16_t, char32_t ou char8_t, que são macros ou typedefs em C (por isso em itálicos, e não em negrito), embora sejam tipos nativos próprios em C++, com as respectivas palavras reservadas).

      • Que fique em aberto para cada implementação escolher se char tem a mesma representação interna de signed char ou de unsigned char.

      • Que o tipo de dados de constantes literais de caracteres (a forma 'x') seja int, em vez de char/signed char/unsigned char (em C++, essa decisão esdrúxula foi parcialmente corrigida: o tipo de 'x' é char, mas ainda não se sabe se esse char tem comportamento mais parecido com signed char ou unsigned char).

      • Que mesmo usando o tipo int para as constantes de caracteres, não se possa dizer inequivocamente apenas olhando o código fonte qual dos dois testes será verdadeiro: “'\377'==0377” e “'\377'==EOF”.



Cuidado com a tradução, porque signed, no caso do qualificador que indica se o tipo de dados pode representar valores negativos, seria mais adequadamente traduzido como com sinal do que como assinado.

Note que essas funções usam como tipo dos ponteiros const void *, não const char *. Elas lidam com a memória bruta, não como strings, e por isso consideram que os dados nessa memória bruta são compostos por bytes, não necessariamente por caracteres de um determinado conjunto de símbolos. E a forma mais habitual de pensar em termos de bytes é considerar que seus valores vão de 0 a 255, sendo menos comum e geralmente restrita a contextos específicos pensar neles como indo de -128 a 127.



Nesse caso não faz diferença. Você não vai comparar elementos da memória bruta com algum outro valor ou copiar um valor que você mesmo forneceu para memória bruta, mas sim copiar “na marra” dados de um tipo qualquer de um lugar da memória para outro. Qualuer tipo intermediário serve, desde que, no fim das contas, os blocos de memória fiquem idênticos.



Acho que as funções poderiam ser mais simples, mas as implementações me parecem atender a especificação das funções.



Exemplo de sobreposição:

char str[]="Paulo";

char *p=str+1;  // mesma coisa que “*p=&s[1]”.

memcpy(p, str, 4);  // XXX: Não se sabe qual resultado isto aqui vai ter! 

A implementação óbvia e simplista de memcpy() seria copiar os bytes em ordem crescente do endereço. Nesse caso, o código acima produziria como resultado o conteúdo "PPPPP" em str. Mas pode ser que alguém saiba que numa determinada plataforma é mais eficiente varrer os endereços de trás para frente, e poderia ficar tentado a ganhar desempenho implementando o algoritmo dessa maneira. Nesse caso, o conteúdo da string resultante em str nessa implementação poderia ser "PPaul".

Ao especificar que as duas regiões de memória não devem se sobrepor, o padrão abre espaço para que a implementação de memcpy() possa usar a implementação mais eficiente possível para a máquina, sem ter de levar em consideração possíveis efeitos colaterais de possíveis sobreposições entre o que ter de ser copiado e o destino da cópia. No entanto, essa responsabilidade passa para o usuário da função, que tem de estar ciente de que se ele desrespeitar a condição de não-sobreposição, pode ter resultados inconsistentes ou comportamento indefinido.

Se o programador souber que existe superposição ou se não tiver como prever se vai ou não ocorrer, ele deve usar outra função, tal como memmove(), que tem um comportamento sempre consistente e previsível, mas possivelmente com menor desempenho.



Na verdade, como eu disse acima, a documentação fala em superposição para que você, como implementador, não precise se preocupar com ela, tornando-a problema do usuário.



Aqui vai muito a questão de gosto. Mas, no caso da afirmação que você citou acima, vai também um bocado de arrogância de quem acha que suas preferências pessoais são boas e que todos os que usam de outro modo são estúpidos ou inferiores — ou hereges —, uma generalização temerária e imprecisa (“tabulações são oito caracteres”, que é verdadeira em muito constextos, mas está longe de ser universal) e uma analogia ruim com tentar alterar o valor de uma constante que não vem de uma convenção (ou, na verdade, de muitas convenções diferentes em diferentes sistemas), mas da descoberta de uma propriedade da Matemática que é imutável em qualquer parte do nosso universo ou, aliás, independente até mesmo da existência de qualquer universo físico.

É uma pena que o criador do Linux seja famoso por esse tipo de falastronice. E é dele, por sinal, a que você citou.

Gosto por gosto, o que eu costumo fazer é usar sempre e exclusivamente tabulação, desabilitando no meu editor qualquer conversão automática de espaços para tabulações ou no sentido oposto. Quem abrir o meu código-fonte e quiser que a tabulação tenha a mesma largura que oito espaços, ou quatro, ou cinco, ou três ou dois, ou vinte e três e dois terços, que ajuste seu editor para tanto. Dá para todo mundo ficar feliz ao mesmo tempo e com o mesmo código.

A não ser que seja uma daquelas pessoas que insistem em usar editores de texto muito queixos-duros, que não têm como ajustar o tamanho da tabulação, ou um daqueles que acham errado usar tabulações flexíveis, e insistem que só uma quantidade fixa de espaços (que depende de quem estiver falando) é que sinaliza virtude. Pensem eles o que quiserem; se não pagam o meu salário, não devo lealdade ao seu masoquismo ou à sua teimosia.


... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)