OpenImageIO/oiio — pull request #694 by lgritz (2013-10-11 17:22:12+00:00)
Title: Make ustring implementation safe for libc++

ustring internally stores the characters for the string and also a std::string representation (so it can return a std::string of the ustring without doing any allocation or construction of it). In order to not allocate the characters twice (once for the C string and once for the std::string), it cleverly doctors the std::string representation to make it point to the same characters. But it's only a trick that (currently) works for gcc's headers, since it's so specific to the std::string internals.

The new libc++ (part of llvm's family of packages) uses a different representation of std::string, but ustring fails to notice because it keys off the definition of __GNUC__. This change excludes the special sauce if __LIBCPP_VERSION is defined.

Note that this is wasteful, in that when building against libc++, every ustring will allocate the characters twice. We should go back and fix that, but it's more work because we have to be super sure it works correctly, and I can't do that easily at the moment because I'm not using a system that uses libc++ (though I use clang, we use gcc's headers).