Just say NO to strlen.

This is a discussion on Just say NO to strlen. within the A Brief History of Cprogramming.com forums, part of the Community Boards category; because you aren't allowed to create user defined functions with those names.
Why not? Just change the parameter type to ...

Why not? Just change the parameter type to char* and return type to int, and you're all good - no ambiguity. Besides, the library functions are supposed to be in the std:: namespace.

Who said this was c++? I might be wrong but I believe that C99 lets you declare variables inside a for loop, which is the only indication that the code might be C++.

Also changing the return type has no barring on overloading. Changing the parameter char * instead of const char * will cause ambiguity for the user. They might expect to get your function but instead will get the standard function if they use a const pointer or const array.

But they aren't built into the compiler, are they? And even if they are, are their specific characteristics built-in too? In some implementations (GNU libc is an example, I think), it is in fact impossible for the compiler to deduce the behaviour of toupper from the code, because the lookup tables are loaded at locale setting time from files on the disk. In other words, the exact behaviour of toupper is not known at compile time.

Which means that the knowledge, "toupper only returns 0 when passed 0" must be built into the compiler.
(On a side note, the _toupper macro that appears in the MS CRT ctype.h header doesn't fulfill this guarantee.)

In other words:

1) The compiler must have been explicitely told that toupper returns 0 only when being passed 0.
2) The compiler must either have been explicitely told, or able to deduce from the (suddenly available) code of strlen (which very often is implemented in assembly), that a loop over a sequence passed to strlen and controlled by its return value can never hit a 0 character in its body.
3) The compiler must either have been explicitely told, or able to deduce from strlen's source, that its return value only changes if a change to the sequence results in a new location of the first 0 character.
4) The compiler must either have been explicitely told, or able to deduce from strlen's source, that strlen has no additional side effects.

Given these three pieces of information, the compiler must follow this line of logic:
Since the loop is controlled by strlen, only non-0 characters will appear in it. The only change to the sequence is the assignment of a value that comes from the same position in the sequence and has been passed through toupper. toupper will only ever return 0 if 0 was passed in, which means that it will never return 0 in this loop, and thus no new 0 characters are introduced inside the loop. Since strlen's return value can never change under these circumstances, strlen can be considered a loop-time constant and can safely be fetched only once.

Changing the parameter char * instead of const char * will cause ambiguity for the user. They might expect to get your function but instead will get the standard function if they use a const pointer or const array.

Indeed, but it's a possibility that the compiler must take into account.

Apparently, the compiler anti-optimized the strlen version for Release build, and optimized the 'proper' version. However, either way the Release build of the strlen version took 149.6 times as long, and the Debug build took 34.8 times as long.

Depending on the compiler this may not be as bad as you think. Since the body of the loop doesn't change the length its very possible for the compiler to modify the code so that the function is called once and it saves the return value and uses that in the condition.

I don't think the compiler can optimize here. Iit doesn't know the side effects strlen has. For instance, strlen could modify errno or some other static variable. Without special code to detect strlen, and if the C library is dynamic or static linked and strlen isn't an inline function, the complier is going to have to assume the worst.