> 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

> 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.