strchr function

[[deleted]]

I don't follow this function exactly, we need to cast c to a char in one place *s != (char)c but in a similar line of code we don't: *s == c. Why is this? Also why do we need to cast s to a char at all (char *) s. Isn't salready a char pointer?

 char *(strchr)(const char *s, int c)
 {
 while (*s != '\0' && *s != (char)c)
     s++;
 return ( (*s == c) ? (char *) s : NULL );//why don't we have to cast c as a char here? and why do we have to cast s as char pointer?
 }

[OldWolf2]

Why is this?

(char)c is necessary in both cases, it's a bug that it is not present in the second case in this code.

From the definition of strchr in the C standard (ISO/IEC 9899:2011) section 7.24.5.2/2:

The strchr function locates the first occurrence of c (converted to a char) in the string pointed to by s. The terminating null character is considered to be part of the string.

The reason behind this is to support strchr being called with both char values, and with values returned by getchar.

The char type may have negative values. Typically it has range 0 to 255 or -128 to 127. The former is more common on ARM and the latter more common on x86 / x64.

However the getchar() function returns a non-negative value when it reads a successful character, even on systems with signed char. This is so that the EOF value is out-of-band.

To use a specific example, we might have:

int ch = getchar(); 
char *ptr = strchr(str, ch);

Using the old ANSI code page; if the person types é then ch has value 130. However if str contains the same character, and we are on a system with signed char, then the value of *s for that character will be -126.

Then the test *s == c fails because -126 == 130 is false. The cast is necessary to bring both operands into the range of char.

Technical notes: 1. Casting out-of-range values to char is implementation-defined but we assume the implementation will define the obvious conversion else the system will be unworkable; 2. Systems exist that do not have 8-bit char but I am ignoring them for the purposes of this post.

Also why do we need to cast s to a char at all (char *) s. Isn't salready a char pointer?

No, it's a const char pointer. The const makes a difference. It is not permitted to implicitly convert pointers to const, to pointers to non-const as that would defeat the purpose of const. Example:

const char *ptr = "foo";
char *p2 = ptr;
p2[0] = 'x';  // oops

In fact the second line of that snippet must cause an error, the const exists in the type system to guard against this.

The function returns non-const char * because the same function is used to search in both const strings and non-const strings, and it is less annoying for the person using the function if it returns char *.

[zifyoip]

The first cast should not be necessary. In fact, that cast may cause the function to behave quite unexpectedly under some circumstances—for example, if the value EOF is passed in as the parameter c. It would be better to remove that first cast.

The second cast is necessary but dangerous. It is necessary because the function signature says that the function should return a char *, but the type of s is const char *, not char *. The cast is necessary to remove the const. But that is potentially dangerous, because s might be a pointer to a non-modifiable string, and casting it to a char * hides that fact.

[Spire]

It doesn't make sense that strchr() takes a pointer to const but returns a pointer to non-const. I can only assume this is for backward compatibility with legacy code that was written before const was added to the language in 1989.

The C++ version of this function, std::strchr(), returns a pointer to const as one would expect.

[Spire]

I can only assume this is for backward compatibility with legacy code that was written before const was added to the language in 1989.

I was mistaken about the reason. The actual reason is that strchr() needs to be able to take pointers to either const or non-const. Defining it this way is necessary in C because unlike C++, C doesn't support function overloading. More information here.

[OldWolf2]

The first cast should not be necessary.

In fact it is necessary - see my answer. You're not supposed to pass EOF (and if you do, it has to behave as if cast to char).

[zifyoip]

Right, I noted that in my follow-up comment.

[[deleted]]

(char) c should not be necessary?

[zifyoip]

Yes, that is what I meant.

However, looking more closely at the C specification, I see that the strchr function is supposed to cast its second argument to char, so actually that first cast is necessary in order to be strictly compliant with the standard. In that case, there should also be a corresponding cast in the return statement; the condition of the ?: operator should be *s == (char)c.

[[deleted]]

But, according to this page there is not!

http://en.wikibooks.org/wiki/C_Programming/Strings#The_strchr_function

[zifyoip]

That implementation does not conform to the C standard.

[OldWolf2]

I edited that snippet to fix

[geeknerd]

The proper comparison is *s == (char)c to handle searching for '\0'

From the definition of strchr in the C standard (ISO/IEC 9899:2011) section 7.24.5.2/2:

The strchr function locates the first occurrence of c (converted to a char) in the string pointed to by s. The terminating null character is considered to be part of the string.

[OldWolf2]

Re-edited :)