Re: [Libreoffice-commits] osl_areCommandArgsSet

On 07/31/2014 10:48 AM, Stephan Bergmann wrote:
> * the documentation of osl_areCommandArgsSet is missing a @since tag;
> please fix
>
> * given that osl_setCommandArgs is deprecated and for internal use only,
> osl_areCommandArgsSet should arguably have been added as internal-only
> functionality ("detail" identifier namespace, "PRIVATE_" ELF symbol map
> namespace); please at least mark it as internal-only in the documentation
>
> * the implementations of osl_areCommandArgsSet
> (sal/osl/unx/process_impl.cxx, sal/osl/w32/process.cxx) are broken as
> they access g_command_args.m_nCount without the corresponding mutex
> locked; please fix

the above have apparently been addressed meanwhile

> * the design of osl_areCommandArgsSet and its use in
> desktop/source/lib/init.cxx are broken, as it is prone to TOCTOU
>
> * adding osl_areCommandArgsSet was unnecessary; given that
> osl_setCommandArgs(0,NULL) is already handled as a special case, that
> case can be extended to silently do nothing if osl_setCommandArgs has
> already been called previously; please fix the LOK use-case that way

the call in LOK is gone now with 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=2163ec3691ece9a00927891645190a971f775295> 
"No need to call osl_setCommandArgs"

> * "and possibly if UNO is being used in addition to LOK in an external
> program": by design, osl_setCommandsArgs is exclusively called from
> sal_detail_initialize, which in turn is exclusively called form
> SAL_IMPLEMENT_MAIN[_WITH_ARGS], and every process that uses binary UNO
> needs to implement main via those macros; note that
> sal_detail_[de]initialize potentially does further things necessary for
> binary UNO to work properly besides calling osl_setCommandArgs; it is
> unwise to hack around that for the LOK use-case in an ad hoc way

has this been considered by the LOK authors?

> * was it necessary to backport osl_areCommandArgsSet to LO 4.3 (given I
> see no mention of LOK in
> <https://wiki.documentfoundation.org/ReleaseNotes/4.3>)?

I'm still interested in an answer here; I'm planing on moving 
osl_areCommandArgsSet to an aborting stub in sal/osl/all/compat.cxx for 
LO 4.4 (after b'porting the above-mentioned 
2163ec3691ece9a00927891645190a971f775295), on the assumption that its 
inclusion in 4.3 was a mistake and it thus will never have been called 
in a released product