¿Se eliminan las funciones stricmp() y strnicmp() en C99? Siempre recibo una advertencia de declaración implícita de función stricmp() (y también strnicmp() ) cuando trato de compilarlo contra C99. Por ejemplo, el código simple a continuación me da esa advertencia.
#include<string.h> #include<stdio.h> char arr[100]="hello"; char arr2[100]="hEllo"; int main() { int n=-1; printf("%d\n",n); n=strnicmp(arr,arr2,3); // the same when use the function stricmp(); printf("%d\n",n); getchar(); return 0; } Cuando trato de compilar este fragmento de código contra C99 ( gcc -Wall -std=c99 main.c -o main ), recibo esa advertencia. Pero cuando lo compilo sin -std=c99 , no aparecerá ninguna advertencia. Sin embargo, aunque hay una advertencia de declaración implícita, mi código sigue funcionando bien.
¿Porqué es eso? ¿Es eso un error? Si no es un error, ¿cuál es exactamente el cambio de C99 que hace que suceda esa advertencia?
Cuando el código se compila con C99, se ajusta al estándar C99, que no tiene stricmp() . Cuando el código se compila sin el interruptor C99, se ajusta a un estándar desconocido que implementa stricmp() . (Dado gcc sin -std=c99 , probablemente compila al estándar C89/90 que permite declaraciones implícitas).
Como comentó @Joachim Pileborg , las comparaciones insensibles no son parte del estándar C.
Con C99, las funciones implícitas requieren un diagnóstico (una advertencia en este caso). Sin C99, el uso implícito de la función no genera ninguna advertencia. Las funciones existen en la biblioteca de este compilador; es solo una cuestión de si las funciones se declaran antes de su uso.
Bastante fácil de hacer el tuyo propio:
int wal_stricmp(const char *a, const char *b) { int ca, cb; do { ca = (unsigned char) *a++; cb = (unsigned char) *b++; ca = tolower(toupper(ca)); cb = tolower(toupper(cb)); } while (ca == cb && ca != '\0'); return ca - cb; } Nota: Al codificar y tratar de hacer que AZ coincida con az , las rutinas de comparación insensibles a las cadenas tienden a funcionar uniformemente bien. Pero cuando se trata de ordenar cadenas, las cosas se salen de control rápidamente. "abc" vs. "_bc" puede ir antes o después del otro dependiendo de si la compasión se hizo en mayúsculas o minúsculas. '_' , en ASCII, existe entre las letras mayúsculas y minúsculas. Con la internacionalización y los problemas locales, la situación se vuelve más compleja. Mi ejemplo de código utiliza un viaje de ida y vuelta de conversión para hacer frente a los problemas en los que el número de caracteres en char no tiene una correlación de 1 a 1 con los de minúsculas. En mi opinión, las complejidades de las comparaciones robustas que no distinguen entre mayúsculas y minúsculas obligan al uso de la codificación UTF y su definición de mayúsculas y minúsculas.
[Editar 2020]
Para hacer frente a las plataformas de complemento no-2 así como a las plataformas de complemento a 2, se justifica una corrección del código. El código anterior doblaría un +0 y -0 en un 0 unsigned . Solo el +0 debería convertirse en 0. Adecuado para leer los datos como unsigned char en lugar de signed char y convertir.
Nota: el manejo adecuado en el complemento distinto de 2 es principalmente académico ahora.
// ca = (unsigned char) *a++; ca = *((unsigned char *) a++); // also cbstricmp y strincmp son funciones no estándar. Nunca han sido parte del estándar C.