why does strchr take an int for the char to be found?

Question

Just curiosity from a c noob.

strchr in std c library looks for a char in a string right?, yet it's signature takes an int c for the search char. And in these two implementations I found, it casts c into to a (char). Does anyone know why? Why not just take a char as parameter?. Thank you

char *strchr(const char *s, int c) {
    while (*s != (char)c) 
        if (!*s++)
            return 0; 
    return (char *)s; 
}

char *strchr(const char *s, int c) {  
    while (*s && *s != (char)c)
       s++;
    if (*s == c)  
      return (char *)s;
    return NULL;
}

Answer 1

In c the type of a character literal is int. For example: 'a' is of type int.

Answer 2

I think this can be attributed to nothing more than an accident of history. You're exactly right that char seems the obvious data type to use for the character being searched for.

In some situations in the C library, such as the getc() function, an int value is returned for the character read from input. This is not a char because an extra non-character value (EOF, usually -1) can be returned to indicate the end of the character stream.

The EOF case doesn't apply to the strchr() function, but they can't really go back and change the declaration of the function in the C library now.

Answer 3

The reasons for that are purely historical. Note, that in the old days of C language (K&R C) there was no such thing as function prototype. A strchr function in those times would be declared as

char *strchr();

and defined in K&R style as

char *strchr(s, c)
  char *s;
  char c;
{
  /* whatever */
}

However, in C language (in K&R C and in the modern one as well) if the function is declared without a prototype (as shown above), the parameters passed in each function call are subjected to so called usual arithmetic conversions. In usual arithmetic conversions any integral type smaller than int (or unsigned int) is always converted to int (or unsigned int). I.e. when the parameters are undeclared, whenever you pass a char value as an argument, this value is implicitly converted to int, and actually physically passed as an int. The same is true for short. (BTW, float is converted to double by the same process). If inside the function the parameter is actually declared as a char (as in the K&R style definition above), it is implicitly converted back to char type and used as a char inside the function. This is how it worked in K&R times, and this actually is how it works to this day in modern C when function has no prototype or when variadic parameters are used.

How, cue in the modern C, which has function prototypes and uses modern-style function definition syntax. In order to preserve and reproduce the "traditional" functionality of strchr, as described above, we have no other choice but to declare the parameter of strchr as an int and explicitly convert it to char inside the function. This is exactly what you observe in the code you quoted. This is exactly as the functionality of strchr is described in the standard.

Moreover, if you have an already-compiled legacy library, where strchr is defined in K&R style as shown above, and you decided to provide modern prototypes for that library, the proper declaration for strchr would be

char *strchr(const char *s, int c);

because int is what the above legacy implementation expects to physically receive as c. Declaring it with a char parameter would be incorrect.

For this reason, you will never see "traditional" standard library functions expecting parameters of type char, short or float. All these functions will be declared with parameters of type int or double instead.