Perils of purpose UNO environments

So-called purpose UNO environments (i.e., the "affine" and "unsafe" ones 
implemented in cppu/Library_affine_uno_uno.mk and 
cppu/Library_unsafe_uno_uno.mk, resp.) are designed to introduce a UNO 
bridge (acting according to a specific "purpose") between different 
regions of C++ code:  Code inside the region (running inside the purpose 
environment) communicates with code outside the region (running in the 
normal C++ UNO environment) only through UNO interface calls, and those 
calls all go through bridged proxy objects (instead of being direct 
native C++ to C++ virtual function calls).

The ado and jdbc drivers in module connectivity use the affine 
environment to restrict those drivers' code to only execute on one 
specific thread (as is presumably required by the underlying ado resp. 
jdbc code that they call into).

Now, code outside the purpose environment can pass a reference to a UNO 
object into the purpose environment (and vice versa) in two ways, one 
good and one bad:

* Good:  Among the arguments or return value of a UNO interface call. 
The bridge will wrap that reference in a proxy, all fine.

* Bad:  Via direct access to global state.  The most prominent example 
is calling comphelper::getProcessComponentContext inside a purpose 
environemnt, which will provide unbridged access to the 
XComponentContext running outside the purpose environment.  So when 
making calls on that XComponentContext from within the purpose 
environment, the called code will suddenly start to wrongly run inside 
the purpose environment!  (This shows why 
comphelper::getProcessComponentContext is a convenient but dumb idea.) 
Another example is the recent 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=03a271901c39d60e4519e67e258d565ad5e1e085> 
"Guard against globally shared UNO ref accessed from wrong UNO env."


PS:  For comphelper::getProcessComponentContext, a patch like

> diff --git a/comphelper/source/processfactory/processfactory.cxx 
> b/comphelper/source/processfactory/processfactory.cxx
> index 211067a..d7ca3af 100644
> --- a/comphelper/source/processfactory/processfactory.cxx
> +++ b/comphelper/source/processfactory/processfactory.cxx
> @@ -18,6 +18,7 @@
>   */
>
>  #include <osl/mutex.hxx>
> +#include <uno/environment.hxx>
>  #include <comphelper/processfactory.hxx>
>  #include <com/sun/star/lang/XMultiServiceFactory.hpp>
>
> @@ -52,11 +53,17 @@ Reference< XMultiServiceFactory > localProcessFactory( const Reference< XMultiSe
>
>  void setProcessServiceFactory(const Reference< XMultiServiceFactory >& xSMgr)
>  {
> +css::uno::Environment env(css::uno::Environment::getCurrent());
> +assert(env.is());
> +assert(env.getTypeName() == CPPU_CURRENT_LANGUAGE_BINDING_NAME);
>      localProcessFactory( xSMgr, true );
>  }
>
>  Reference< XMultiServiceFactory > getProcessServiceFactory()
>  {
> +css::uno::Environment env(css::uno::Environment::getCurrent());
> +assert(env.is());
> +assert(env.getTypeName() == CPPU_CURRENT_LANGUAGE_BINDING_NAME);
>      Reference< XMultiServiceFactory> xReturn;
>      xReturn = localProcessFactory( xReturn, false );
>      if ( !xReturn.is() )

could catch cases where it erroneously gets called from within a purpose 
environment.  Then again, purpose environments are rare enough in 
practice, and I only found a single problematic 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=9610a5aebd3ffdf76bcb734c633b5f88b78ad4dd> 
"Use passed-in context instead of 
comphelper::getProcessComponentContext()" when running "make check" with 
that patch enabled.  So it might not be worth it to commit that.