It's not, in my opinion, an increase in maintainability.

It requires you to handle multiple possible return values when there are really only 2 possible return values.

If our code calls an internal function incorrectly, it doesn't do any good to report that error to the user or client of the library, and if we are doing that in release code then we have a problem.

The proper thing to do is ensure that we are always providing the correct parameters, so that we don't have to check them. And it's easier to make sure we're doing that when not checking them leads to crashes.

If it were a public/external API, or performed any kind of memory allocation, I'd be all for it using a status enum. But for what the function is doing, it's just not necessary.

The code was originally modified from a C library function strnstr http://opensource.apple.com/source/Libc/Libc-320/string/FreeBSD/strnstr.c which can be seen here. These do not perform any checks on parameters, because it's the responsibility of the caller to ensure that they're valid. The same is true for our implementation, it makes code simpler and more readable to not return a status for functions like this.

There is literally nothing that could go wrong if the function is called correctly, so the solution is to make sure it's called correctly.