As a library author, the worst thing I have to deal with is PHP settings that affect global behaviour. Some examples of this include:

• Making sure that the library still works in your specific locale setting.
• Don't rely on a specific error_reporting setting to catch errors.
• If it was 1997, don't rely on a specific magic_quotes or register_globals setting.
• Don't rely on the current setting of mb_internal_encoding, and instead always pass the desired encodings to the mb_* functions.

Not only should I not rely on these settings, I also can't change them. I should assume that the application using my library might have a preference for a specific setting, so I can't dictate what the setting should be. The exception to this are cases where I change a setting temporarily and revert it.

Obviously I'm not perfect and not aware of every flag that changes the environment. When I come across incompatibility bug reports I'll quickly try to change the bits that affect this compatibility.

So now I'm faced with a bug report about my library failing when mbstring function overloading is turned on. Definitely something I've missed.

mbstring overloading alters the behaviour of 17 common PHP string functions, such as strpos and substr. Because I deal with binary data this fails on a number of places. The only solution is to look for all the instances where I'm using these functions and replace instances of strlen($string) with mb_strlen($string, '8bit');.

I'm using these functions on a ton of places though. I'm wondering in this case if I should simply throw an error when I find out function overloading is turned on.

Conclusion

To make a long story short. If you're ever intending to use external PHP libraries, there's a very good chance they haven't accounted for mbstring.func_overload. I can highly recommend always using the mb_* functions directly, and keep that setting off.