Question

I found this typo recently:

 if (name.find('/' != string::npos))

Obviously the dev meant to type

if(name.find('/') != string::npos)

But I was amazed that to find that the error even compiles with -Wall -Werror (didnt try with -pedantic)

So, coffee quiz: does it evaluate to true or false?

Answer 1

‘/’ doesn’t equal string::npos since npos is required to be negative, and none of the characters in the basic execution character set is allowed to be negative. Therefore, it’s going to look for a value of 1 in the string (presumably a string anyway) represented by name. That’s a pretty unusual value to have in a string, so it’s usually not going to find it, which means it’ll return std::string::npos, which will convert to true.

Edit: as Johannes pointed out, although the value assigned to npos must be negative 1 (as per 21.3/6) that’s being assigned to a size_type, which must be unsigned, so the result won’t be negative. This wouldn’t normally make any real difference though — the ‘/’ would be compared to npos using unsigned arithmetic, so the only way they could have the same value would be if 1) ‘/’ was encoded as -1 (not allowed as above) or char had the same range as size_type.

In theory, the standard allows char to have the same range as other integral types. In fact, quite a bit of I/O depends on EOF having a value that couldn’t originate from the file, which basically translates to a requirement that char have a range that’s smaller than int, not just smaller than or equal to (as the standard directly requires).

That does leave one loophole, though it’s one that would generally be quite horrible: that char and short have the same range, size_type is the same as unsigned short, and int has a greater range than char/short. Giving char and short the same range wouldn’t be all that horrible, but restricting size_type to the same range as short normally would be — in a typical case, short is 16 bits, so it would restrict containers to 64K. That kind of restriction was problematic 20 years ago under MS-DOS; it simply wouldn’t be accepted in most markets today.