Is the functions stricmp()
and strnicmp()
removed in C99?
I always get warning implicit declaration of funtion stricmp() (and also strnicmp() ) when I try to compile it against C99.
For example, the simple code below get me that warning.
#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;
}
When I try to compile this piece of code against C99(gcc -Wall -std=c99 main.c -o main
), I get that warning. But when I compile it without the -std=c99
, no warning will be thrown.
However, even though there is warning of implicit declaration, my code still work out right.
Why is that? Is that a bug? If not a bug, then what is exactly the change of C99 which make that warning happen?
When code compiles with C99, it conform to the C99 standard, which does not have
stricmp()
. When code compile without C99 switch, it conforms to an unknown standard that implementsstricmp()
. (Givengcc
without-std=c99
, likely compiles to the C89/90 standard wihich allows implicit declarations.)As @Joachim Pileborg commented, insensitive compares are not part of the C standard.
With C99 implicit functions require a diagnostic (a warning in this case). Without C99, the implicit use of the function generates no warning. The functions exists in this compiler's library - it is just a question of are the functions declared before use.
Easy enough to make your own:
Note: When coding and trying to make
A-Z
matcha-z
, string insensitive compare routines tend to work uniformly well. But when trying to to order strings, things quickly get out of hand. "abc" vs. "_bc" can come before or after the other depending on if compassion was done as upper or lower case.'_'
, in ASCII, exists between the upper and lower case letters. With internationalization and locale issues, the situation becomes more complex. My code example uses a round-trip of conversion to cope with issues where the number of uppercasechar
does not have a 1-to-1 mapping with lowercase ones. IMO the complexities of robust case insensitive compares obliges the use of UTF encoding and its case definition.[Edit 2020]
To cope with those forlorned non-2's complement as well as 2's complement platforms, a code correction is warranted. Earlier code would fold a +0 and -0 into an
unsigned
0. Only the +0 should convert to 0. Proper to read the data asunsigned char
rather thansigned char
and convert.Note: the proper handle in non-2's complement is mostly academic now.