> also it's the "safer" version of strcmp when used with n calculated another way

This isn't true; first off it isn't "safer" than strcmp() at all (this isn't strcpy vs strncpy after all), and second, no length argument to strncmp() will make it act like strcmp(). In order to get strcmp(), you have to also check the lengths are the same first.

    strlen(a) == strlen(b) && strncmp(a, b, strlen(either))

This is less safe than using strcmp() when you want equality (as this Intel issue shows) because it is easy to forget the length check. strcmp() does it implicitly for you.

I agree the names are not ideal (in fact I write my own streq() and strpfx() routines because I think it reads easier and it is also easy to get the return value of strcmp() wrong), but again, that has nothing to do with separating the string's pointer and its length.

I agree with you, but please argue with the other person who objected to my comment saying that strncmp was obviously the safer version of strcmp. :-)

An API where experienced users don't even agree what the function is supposed to be is a bad API.

How do you know all parties involved in this discussion are experienced?